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
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






Cocoa mail archive

