RE: Convenience Methods
RE: Convenience Methods
- Subject: RE: Convenience Methods
- From: Erik Buck <email@hidden>
- Date: Wed, 26 Sep 2007 20:19:05 -0400
There are in theory substantial advantages to using immutable objects
and immutable collections. One theoretical advantage of immutable
objects is substantial optimization from implementing -copy as
- (id)copy
{
return [self retain];
}
In theory, collection enumerators get simpler (and faster) when used
with immutable collections. Pass by value (which can be expensive)
is less necessary when using immutable objects. It is safe to
directly return immutable instance variables...
I don't know if NeXT or Apple ever provided truly immutable objects
like NSString, NSArray, etc. With the adoption of Core Foundation
and toll free bridged classes, any theoretical advantages of true
immutability were completely abandoned. Without true immutability,
it is certainly valid to wonder why Cocoa maintains the (now
artificial) distinction between supposedly immutable classes and
their mutable subclasses.
Sadly, I suspect the only reason that NSMutableArray and friends
continue to exist is so that "legacy" Cocoa code would not break.
Nothing stops Apple from re-factoring and moving the mutation methods
into the base classes now. NSMutableArray and friends would just
become vestigial framework support for "old" code.
Alternatively, Apple could decide to create NSCFImmutableArray or
take other steps to restore true immutability. Apple is
inscrutable! From my perspective, Apple currently has the worst of
both worlds: They have the clutter and complexity of distinctions
between mutable and immutable classes; They don't get any benefits
from immutable classes because they aren't really immutable.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden