Re: Is Apple's singleton sample code correct?
Re: Is Apple's singleton sample code correct?
- Subject: Re: Is Apple's singleton sample code correct?
- From: Shaun Wexler <email@hidden>
- Date: Thu, 1 Dec 2005 21:22:36 -0800
On Dec 1, 2005, at 9:12 PM, Charilaos Skiadas wrote:
Actually this is a very good example. In this case, you want to
work with this string and make sure that nothing you don't have
control over will change it, and so you want to copy it. You
shouldn't be concerned whether it's actually an NSString, or an
NSMutableString disguised as a string.
I think this is very different than the singleton case though. The
same document (NSCopying Protocol) says:
The exact meaning of “copy” can vary from class to class, but a
copy must be a functionally independent object with values
identical to the original at the time the copy was made"
By "functionally independent" I take it to mean that if you change
any of the values of the object and its variables, then this only
changes the object that you have as a copy. You don't expect that
change to carry over to the original object. In the case of the
immutable classes, that's a moot point, but in the case of a
singleton, the object variables of the copy are the same as the
object variables of the original, which I think breaks the contract
of the NSCopying protocol. Please correct me if I am wrong here.
In the case of a class cluster and/or a mutable subclass of an
immutable class, -copy returns an immutable object, without affecting
the original object. Mutable copying should only be implemented if
the class conforms to the NSMutableCopying protocol, and defining
those methods in a singleton base class (without declaring the
protocol) makes it a subclass responsibility, without adding
unnecessary complication to implementations, since protocols can be
checked at runtime anyway.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
"I never let schooling interfere with my education." - Mark Twain
_______________________________________________
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