Re: Mutable class problems
Re: Mutable class problems
- Subject: Re: Mutable class problems
- From: Marco Scheurer <email@hidden>
- Date: Wed, 26 Jun 2002 16:32:19 +0200
On Tuesday, June 25, 2002, at 05:40 pm, Michael Tsai wrote:
On 6/25/02 at 5:00 PM, Ondra Cada <email@hidden> wrote:
On Tuesday, June 25, 2002, at 03:54 , Andy Lee wrote:
I have a slight quibble with this class design, which is having
NSMutableThing subclass from NSImmutableThing. A subclass should
extend its superclass, not adopt a behavior which is expressly
banned in the semantics of the superclass.
It does that, exactly. I fear you don't understand the
(im)mutability design completely.
I think Andy does understand it but he's troubled that it violates the
LSP:
<http://www.dictionary.com/search?q=Liskov substitution principle>
<http://www.brent.worden.org/tips/2000/liskovSubstitutionPrinciple.html>
IMHO this is not a violation of the LSP, but a violation of the semantic
implied by the choice of names. MutableThing inherits from
ImmutableThing implies that the following sentences are true:
"MutableThing is a kind of ImmutableThing"
"mutableThing is a ImmutableThing"
This choice of names is clearly embarassing. At least, in Foundation,
nothing qualifies the superclass names: NSMutableArray inherits from
NSArray, mutableThing is a Thing.
I am too, though I have to admit that the current design hasn't
caused me any problems (yet). I like the Foundation design better
than the way Java does it. In Java, you can have mutable and
immutable objects at runtime but only mutable interfaces to use in
your source. (And you can only create immutable objects by wrapping
mutable ones--there's nothing like arrayByAddingObject:.) With
Foundation, at least you can use the types to communicate intent. I
doubt it's possible to do better than that in a language like ObjC
while still keeping an API that's simple to use.
The design is fine. One could question this Thing / MutableThing choice,
because it does not scale very well: for instance, if you want to
subclass and add BetterThing and BetterMutableThing, you have a hard
choice to make: should BetterMutableThing inherit from BetterThing or
from MutableThing? In practice, this is not so much of a problem because
subclassing NSArray, NSDictioanry or NSString is rarely done and not
very useful.
The problem raised by Ondra is with the implementation (NSArray and
NSMutableArray are abstract classes, and what you get always is an
instance of a subclass of NSMutableArray), and its result: you cannot
distinguish at runtime between an immutable and a mutable instance
NSArray without resorting to trying to raise an exception.
In practice, this is not a huge problem, because just as testing for
class membership is bad practice, I think that testing for mutability at
runtime would be a bad idea.
This is a problem if you want to extend, in different ways, NSArray and
NSMutableArray, as was demonstrated in this thread. Categories do not
work with the current implementation of the clusters, but they could
work with another implementation of the same design.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.