Copy and release
Copy and release
- Subject: Copy and release
- From: Nicko van Someren <email@hidden>
- Date: Thu, 21 Oct 2004 16:35:59 +0100
In discussion over a beer the other day a friend and I felt that the
NSCopying protocol needed extending with a new compound operation,
"Copy and Release". I would be interested to hear the opinions of
people on this list regarding the subject.
It is quite common when writing programs for Cocoa that a data
structure needs to be mutable while it is being filled but after that
it would be useful for it become immutable in order to take advantage
of the efficiencies that affords once the object has been set up. As
it stands the only way to do this that I can find is to copy and
release and I suggest that this should be a method of NSObject
implemented thus:
- (id) copyAndRelese {
id copy = [self copy];
[self release];
return copy;
}
Clearly this is trivial to add using an NSObject category but I think
it makes sense for this to be added in in a more permanent manner, and
required by the NSCopying protocol, because in many case the
implementation can be improved on. Consider the case where a class
knows itself to be immutable; it can implement copyAndRelease thus:
- (id) copyAndRelese { return self; }
Furthermore, in many cases in the foundation classes we actually have
class clusters. An NSData and an NSMutableData are the same thing with
different method sets while certain instances of NSString and
NSMutableString are implemented with the same class and different flags
internally, as are NS(Mutable)Dictionary and NS(Mutable)Array. This
means that in such class clusters the implementation of copyAndRelease
in some mutable version might look thus:
- (id) copyAndRelese {
if ([self retainCount] == 1) {
return [self magicMeImmutable];
} else {
return [super copyAndRelease];
}
}
Where the magicMeImmutable message returns self after either playing
with the isa pointer or resetting some internal mutability flags in a
class-cluster specific manner.
The reason I think that makes sense to bother doing this is that I
suspect that in the vast majority of cases the retain count will equal
one in the places where a programmer currently wants to call
copyAndRelease. Most programs I write need to fill an NSArray or
NSDictionary with data but once filled it is frequently the case that
these objects don't need to be altered. The trivial implementation of
copyAndRelease can be pretty slow on a large mutable array or
dictionary but it's not possible to retrofit the efficient
implementation without knowledge of the implementation. So my
assertion is that by adding this message to the NSCopying (or possibly
NSObject) protocol we can give every class(-cluster) author the option
of providing the efficient implementation if they can.
So, what do people think? Is this useful enough to warrant a feature
request to Apple? Are there other ways to do this?
Nicko
_______________________________________________
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