gnustep-dev
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]