Re: Mutable class problems
Re: Mutable class problems
- Subject: Re: Mutable class problems
- From: Andy Lee <email@hidden>
- Date: Tue, 25 Jun 2002 09:54:22 -0400
At 2:00 PM +0200 6/25/02, Ondra Cada wrote:
The right thing would be to dispense with the CoreFoundation thing,
and return to the clean ObjC-based Foundation, in which the class
pattern is very natural and intuitive:
NSObject
ImmutableInterfaceClass
ImmutableHiddenSubclass1
...
ImmutableHiddenSubclassN
MutableInterfaceClass
MutableHiddenSubclass1
...
MutableHiddenSubclassM
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.
The practical implication of this is that you can never rely on
compile-time type-checking to be sure that a thing won't be changed
out from under you. You can never write a method of the form...
- (void)foo:(NSImmutableThing *)aThing
{
// Do stuff that absolutely needs aThing to *not* mutate.
}
...without adding a check like this:
- (void)foo:(NSImmutableThing *)aThing
{
if (![aThing isMutable])
{
// Do stuff that absolutely needs aThing to *not* mutate.
}
else
{
// Raise an exception? Return an error code? Ignore?
}
}
If you want to rely on class membership to tell you whether an object
is mutable, you have to do something like this:
NSObject
NSThing // guarantees nothing
NSMutableThing // guarantees mutability
...
NSImmutableThing // guarantees non-mutability
...
But then you run into the next problem, which is that mutability is
not the only attribute you may want to distinguish. Collections, for
example, have attributes like ordered, allows-duplicate, and
keyed-vs.-indexed. To express all combinations of these distinctions
by class membership alone, you'd need a really hairy 2^n-member class
hierarchy with long ridiculous class names. Not acceptable. So at
some point you're stuck with runtime checks like -isOrdered,
-allowsDuplicate, etc. But at least with the design immediately
above this paragraph you've been able to make one distinction --
mutable vs. not -- at compile time.
But I'm getting long-winded in response to an original question
Rosyna resolved already! Good thing I have to run to a computer show
now. I'm late in fact...
--Andy
_______________________________________________
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.