Re: only defined for abstract class
Re: only defined for abstract class
- Subject: Re: only defined for abstract class
- From: Kay Roepke <email@hidden>
- Date: Fri, 7 Oct 2005 01:37:35 +0200
On 6. Oct 2005, at 20:18 Uhr, Mark Munz (DevList) wrote:
On Oct 6, 2005, at 12:43 PM, Francis Derive wrote:
The concept article makes it clear that you can't call the
inherited object for primitive methods.
I has yet to be clear to me - but I am obliged to be conviced.
Francis, the inherited methods count -and -objectAtIndex: are
considered abstract. The thing is that Objective-C actually doesn't have
the language equivalent of "abstract methods" as e.g. Java has. (In
other words, there's no compiler keyword 'abstract', it's simply not
a language feature.)
To still be able to make methods abstract an force the subclasser to
implement them, typically an exception is raised, or a message
doesNotImplement is sent (This stems from Smalltalk, which also has
no abstract keyword.).
Enough history: NSArray and NSMutableArray are two publicly visible
classes of the class cluster "Arrays". They provide all
the basic methods needed for an array. They do their work in terms of
their respective "primitive methods".
For NSArray those are -count and -objectAtIndex:.
So when you make a custom subclass of NSArray, you have to provide
those to methods in your subclass. You cannot call the superclass's
(NSArray's)
methods, because those just raise the exception all over again. In
this case overriding really means that: You completely replace the
"placeholder"
methods of your superclass.
Hope that helps :-) (Although this was just the paraphrase of the
docs...)
By the way, if I understand well the third statement of a True
Subclass : "Override the superclass's primitive methods", where
does NSMutableArray overrides the NSArray's -count and -
objectAtIndex: ? Bizarre.
As I understand it, the primitives listed are specific to the
class. I assume you need to include both the NSArray and
NSMutableArray (the docs aren't clear on this point). It looks like
the docs assume you would only ever write to an NSMutableArray, but
not read from it.
I think ALL the methods should be listed in the case of mutable
variants, since you'll likely need to access the class for reading
as well as writing.
This is a common problem (IMHO) with the Apple docs. You cannot see
from one class description which methods are inherited. One could say
the
Apple doc writers are correct in this issue as the inherited methods
don't really belong to this class, but still this makes it hard
sometimes
to glance over all the messages an object will respond to (not
considering such things as forwardInvocation:).
Because NSMutableArray inherits from NSArray, its subclasses
naturally need to supply concrete implementations of -count and -
objectAtIndex:, too, since
NSMutableArray still cannot provide them itself (It still is an
abstract class - it merely adds different abstractions to NSArray).
You have to define that either as your own storage type, or the
other option is the composite example (where you wrap around the
NSMutableArray, in which case you have an embedded NSMutableArray).
I had done this way at first, but wanted to explore the
alternative of subclassing ...
In both cases, you're subclassing NSMutableArray. The wrapping
option differs only in that you're actually using another instance
of NSMutableArray to help implement your primitives. You're just
using another instance of NSMutableArray to do the storage work for
you.
To provide a custom implementation of an NS(Mutable)Array subclass
should be overkill in most situations. I'd rely on the existing
concrete subclasses being
thoroughly optimized for many special cases. Unless you really have a
pressing need to have an even more efficient array (memory- or time-
wise) I wouldn't
even think about not compositing an NSArray subclass to do the work.
Regards,
Kay
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden