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: glenn andreas <email@hidden>
- Date: Wed, 30 Nov 2005 08:35:27 -0600
On Nov 30, 2005, at 2:18 AM, Scott Anguish wrote:
On Nov 30, 2005, at 12:59 AM, Jeff Laing wrote:
myColor = [[NSColor whiteColor] retain];
Hmmm, I had not considered that that would be returning a
singleton at all.
Singleton implies a single instance for the entire class, and
this doesn't return the same object if you call, for example redColor.
These are convenince methods for creating colors. it's subtle, but
I believe it'd be more accurate to say that it returns a shared
immutable object that represents white, rather than a singleton for
NSColor. you'll get a different object for redColor, but again,
likely the same object again if you ask for it again (assumptions
being made on my part here about how this particular aspect works,
I've not checked)
Well, there could be an NSWhiteColor subclass, whose singleton is
returned for NSColor whiteColor, but how about a nice non-theoretical
example:
[self setValue: [NSNull null]]
where:
- (void) setValue: (NSValue *) value
{
[myValue autorelease];
myValue = [value retain];
}
NSNull's null is pretty clearly a singleton ("returns the unique
instance of NSNull"), but since it's also an NSValue (which are
usually not singletons) you would end up applying the same retain
rules as any other NSValue (as shown in the above example).
So this is a pretty simple example of a singleton that has retain/
release called on it.
there are other kit cases where shared immutable objects are
returned that you don't necessarily know about. bottom line is, if
you want to ensure that you have a valid reference to it, retain
it. no exceptions (well, weak references I suppose)
Exactly.
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | build, mutate, evolve | images, textures, backgrounds, art
_______________________________________________
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