[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Class clusters: MacOSX/GNUstep differences?
From: |
Ronan Collobert |
Subject: |
Re: Class clusters: MacOSX/GNUstep differences? |
Date: |
Wed, 1 Sep 2004 23:33:24 +0200 (CEST) |
Hey,
> I'm pretty certain that the OpenStep specification did not say this ...
> because at some point when working on class clusters I wanted a clear
> policy on initialisation and couldn't find anything in the spec ...
> though I do remember finding something saying that a subclass needed to
> override the superclass initialisers in order to prevent those
> initialisers returning instances of other classes. I therefore adopted
> the policy that class clusters should, like any other class, have
> designated initialisers. Also that, like other classes, the designated
> initialiser should be the 'richest' initialiser. So that, in GNUstep it
> should be possible to override a single designated initialiser and have
> all the other initialisers work as expected, ie to improve on the
> OpenStep spec That's why the GNUstep class documentation specifies the
> designated initialiser of NSArray to be initWithObjects:count:
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. 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).
> 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.
GNUstep users who want to use NSArray initializers would be able to
redefine initWithObjects: anyway. Or maybe:
- (id) initWithObjects: (id*)objects count: (unsigned)count
{
#ifndef NO_GNUSTEP // or #ifndef STRICT_MACOS_X
[self subclassResponsibility: _cmd];
#endif
return nil;
}
Cheers,
Ronan.