Re: Class clusters: MacOSX/GNUstep differences?

[Richard Frith-Macdonald]

On 1 Sep 2004, at 22:33, Ronan Collobert wrote:

> I understand your choice, and I agree that sometimes it can be 
> interesting
> to have all the init method of the super class when subclassing. 
> However,
> I think it is debatable, because one of the main interest of 
> subclassing
> NSArray (or NSDictionary or NSSet) is when the storage of the subclass 
> is
> different.

Sure, but there are lots of instances where using some or all of the 
initialisers
is helpful for the case of the different storage.  For instance, when 
an array
stores in a linked list, or a sparse array of some sort.

>  This is a quote of apple documentation:
>
> "If you find that a cluster doesn't provide the functionality your 
> program
> needs, then a subclass may be in order. For example, imagine that you 
> want
> to create an array object whose storage is file-based rather than
> memory-based, as in the NSArray class cluster. Since you are changing 
> the
> underlying storage mechanism of the class, you'd have to create a
> subclass."
>
> In that kind of case, the initWithObjects: initializers are non-sense 
> (it
> would be for example initWithFile: instead).

Sure, new subclasses add new initialisers which call the designated
initialiser.
It's no more of a nonsense to call -initWithObjects:count: than to call 
-init
(you can call it with nil and zero as arguments).
Indeed, the -initWithObjects:count: might store objects to a temporary 
file
and thus do something useful, while a call to -init would not.  It all 
depends
how you want to design your subclass.  The aim of designated 
initialisers
is to make as much of the superclass usable by subclasses as possible,
thus saving effort in many cases ... it's not going to help for all 
cases, but
it's never going to be worse than the MacOS-X scheme.

> > I'm reluctant to make things harder for GNUstep coders by forcing them
> > to implement initialisers that the abstract class ought to handle, 
> > but I
> > can't immediately see an elegant portability solution.
>
> What about changing in NSArray.m (and similar thing for other container
> classes)
> - (id) initWithObjects: (id*)objects count: (unsigned)count
> {
>   [self subclassResponsibility: _cmd];
>   return nil;
> }
>
> by
> - (id) initWithObjects: (id*)objects count: (unsigned)count
> {
>   return nil;
> }
>
> In that case, it doesn't force the implementation of initWithObjects:, 
> and
> a call to the init method of NSArray in a subclass will still work.

I think that looks quite reasonable ... though you would want the 
default
implementation of -initWithObjects:count: to return self rather than nil
wouldn't you?