Skip navigation.
 
mlRe: Releasing uninitialized objects: proper procedure
FROM : Greg Hurrell
DATE : Sat Jun 10 15:10:23 2006

El 09/06/2006, a las 18:58, Christiaan Hofman escribió:

> On 9 Jun 2006, at 12:51 PM, Greg Hurrell wrote:
>

>> El 09/06/2006, a las 8:51, Uli Kusterer escribió:
>>

>>> Am 07.06.2006 um 16:32 schrieb Chad Leigh:

>>>> On Jun 7, 2006, at 8:20 AM, Greg Hurrell wrote:

>>>>> El 06/06/2006, a las 19:03, Adam Maxwell escribió:
>>>>>

>>>>>> @interface NSDate (extensions) @end
>>>>>> @implementation NSDate (extensions)
>>>>>>
>>>>>> - (id)initAsCalendarDate
>>>>>> {
>>>>>>  [[self init] release]; // this works, but seems wrong
>>>>>>  [self release];        // this hangs, so it must be wrong
>>>>>>  return [[NSCalendarDate alloc] init];
>>>>>> }
>>>>>> @end

>>>>>

>>>> (...)
>>>> I have not been following the details but I don't think the 
>>>> example is one that would be useful in real life but is rather a 
>>>> contrived example to show changing the underlying object type in 
>>>> an init section.

>>>
>>>  Well, then I guess class clusters like NSString aren't useful in 
>>> real life either? Or NSArray? Most of these return instances of 
>>> (private) subclasses of NSString etc. when you init a new one.

>>
>> True, but Apple's class clusters don't work like the NSDate/
>> NSCalendarDate example above; they allocate instances of 
>> intermediate placeholder classes (with names like 
>> "NSPlaceholderMutableArray" and "NSPlaceholderArray") and return 
>> initialized concrete subclasses (with names like "NSCFArray") of 
>> the public abstract classes ("NSArray", "NSMutableArray" etc).
>>
>> Cheers,
>> Greg

>
> Of course unless you make a subclass of a class cluster (as was the 
> case for the situation that led me to this question). Then Apple's 
> class cluster's *do* create an allocated instance of the subclass, 
> not a placeholder. Moreover, officially you're not supposed to rely 
> in anyway on the placeholder, as it's a private class. So in that 
> case, the 'contrived' example above is exactly what you *should* do 
> (apart from the extra [self release]).


Well once again, I come back to my original question:

How is:

[[NSDate alloc] initAsCalendarDate]

Better than?

[[NSCalendar alloc] init]

Is there anywhere else in Cocoa where such a pattern is implemented? 
For example:

[[NSString alloc] initAsMutableString]

Why stop there? Why not?

[[NSObject alloc] initAsAppleEventDescriptor]

etc...

Basically, I asked the question originally because the example 
smelled like bad design that runs against the grain of the typical 
Cocoa conventions and design patterns, and for which a much better 
and more correct alternative exists ([[NSCalendarDate alloc] init]). 
I just wanted to make sure that the original posted wasn't 
unwittingly making any bad design decisions. If it really was just a 
"contrived example", and clearly labelled as something you wouldn't 
want to do, then great. A better (non-contrived) example would 
probably have been more appropriate though (ie. if your real concern 
is about subclassing a class cluster it would probably be better to 
use an example drawn from that actual case).

Cheers,
Greg

Related mailsAuthorDate
mlReleasing uninitialized objects: proper procedure Christiaan Hofman Jun 6, 16:58
mlRe: Releasing uninitialized objects: proper procedure Paul Lynch Jun 6, 17:15
mlRe: Releasing uninitialized objects: proper procedure Christiaan Hofman Jun 6, 17:41
mlRe: Releasing uninitialized objects: proper procedure j o a r Jun 6, 17:50
mlRe: Releasing uninitialized objects: proper procedure Paul Lynch Jun 6, 17:57
mlRe: Releasing uninitialized objects: proper procedure Christiaan Hofman Jun 6, 17:57
mlRe: Releasing uninitialized objects: proper procedure j o a r Jun 6, 18:06
mlRe: Releasing uninitialized objects: proper procedure Markus Hitter Jun 6, 18:32
mlRe: Releasing uninitialized objects: proper procedure Adam Maxwell Jun 6, 19:03
mlRe: Releasing uninitialized objects: proper procedure Shawn Erickson Jun 6, 19:45
mlRe: Releasing uninitialized objects: proper procedure Christiaan Hofman Jun 6, 19:58
mlRe: Releasing uninitialized objects: proper procedure Dietmar Planitzer Jun 6, 22:58
mlRe: Releasing uninitialized objects: proper procedure Christiaan Hofman Jun 7, 02:02
mlRe: Releasing uninitialized objects: proper procedure Greg Hurrell Jun 7, 16:20
mlRe: Releasing uninitialized objects: proper procedure Chad Leigh Jun 7, 16:32
mlRe: Releasing uninitialized objects: proper procedure Adam R. Maxwell Jun 9, 04:55
mlRe: Releasing uninitialized objects: proper procedure Uli Kusterer Jun 9, 08:51
mlRe: Releasing uninitialized objects: proper procedure Greg Hurrell Jun 9, 11:51
mlRe: Releasing uninitialized objects: proper procedure Christiaan Hofman Jun 9, 18:58
mlRe: Releasing uninitialized objects: proper procedure Greg Hurrell Jun 10, 15:10