[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Class clusters: MacOSX/GNUstep differences?
From: |
Richard Frith-Macdonald |
Subject: |
Re: Class clusters: MacOSX/GNUstep differences? |
Date: |
Wed, 1 Sep 2004 23:55:36 +0100 |
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?