FROM : Jens Alfke
DATE : Sun Feb 10 20:45:00 2008
On 10 Feb '08, at 9:18 AM, Scott Andrew wrote:
> I see Will, and a few others, say no [super init] will initialize
> self in its code there is no reason to assign self.
No, you do [sometimes] need to assign self. 'self' is just a local
variable (actually a parameter, one declared for you by the compiler.)
The superclass's init method can't affect its value for you. However,
in some cases the superclass method can decide to return a different
object, and in that case unless you reassign self, you won't get the
object the superclass initialized.
Why would an init method return a different object? Usually because
it's part of a "class cluster" design pattern, where the public class
is abstract, and behind the scenes some concrete subclasses are used.
Most of the Cocoa collection classes work this way. When you call "-
[[NSArray alloc] init] the result isn't an instance of NSArray, it's
usually an NSCFArray, an internal class that manages the bridging to
CoreFoundation's CFArray.
Another reason is to take advantage of variable-sized objects. You
could have an array-like class that stores its array in itself, past
the end of its regular instance variables. To do that, you have to
call NSAllocateObject passing in the number of extra bytes to reserve.
But you don't know that size until your -initWithSize: is called,
after you've been allocated. So you make your -initWithSize call [self
release], then NSAllocateObject with extra bytes, and assign that to
self. The result is that -initWithSize returns a different instance
than it was called on.
Any subclass that calls [super initWithSize] and doesn't reassign self
to the result now has a 'self' variable that points to an obsolete
dealloced object, and is now very likely to either crash immediately
or (more likely) corrupt the heap and cause a later crash. Bad news.
-init methods that return a new object are rare. In most cases you
don't need to add "self=" in front of the "[super init]" call. But in
those few cases the consequences are grim, so it's better to train
yourself to do it every time. It's only five more characters to type,
and it should only compile into one or two extra machine instructions.
—Jens_______________________________________________
Cocoa-dev mailing list (<email_removed>)
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:
http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
This email sent to <email_removed>
DATE : Sun Feb 10 20:45:00 2008
On 10 Feb '08, at 9:18 AM, Scott Andrew wrote:
> I see Will, and a few others, say no [super init] will initialize
> self in its code there is no reason to assign self.
No, you do [sometimes] need to assign self. 'self' is just a local
variable (actually a parameter, one declared for you by the compiler.)
The superclass's init method can't affect its value for you. However,
in some cases the superclass method can decide to return a different
object, and in that case unless you reassign self, you won't get the
object the superclass initialized.
Why would an init method return a different object? Usually because
it's part of a "class cluster" design pattern, where the public class
is abstract, and behind the scenes some concrete subclasses are used.
Most of the Cocoa collection classes work this way. When you call "-
[[NSArray alloc] init] the result isn't an instance of NSArray, it's
usually an NSCFArray, an internal class that manages the bridging to
CoreFoundation's CFArray.
Another reason is to take advantage of variable-sized objects. You
could have an array-like class that stores its array in itself, past
the end of its regular instance variables. To do that, you have to
call NSAllocateObject passing in the number of extra bytes to reserve.
But you don't know that size until your -initWithSize: is called,
after you've been allocated. So you make your -initWithSize call [self
release], then NSAllocateObject with extra bytes, and assign that to
self. The result is that -initWithSize returns a different instance
than it was called on.
Any subclass that calls [super initWithSize] and doesn't reassign self
to the result now has a 'self' variable that points to an obsolete
dealloced object, and is now very likely to either crash immediately
or (more likely) corrupt the heap and cause a later crash. Bad news.
-init methods that return a new object are rare. In most cases you
don't need to add "self=" in front of the "[super init]" call. But in
those few cases the consequences are grim, so it's better to train
yourself to do it every time. It's only five more characters to type,
and it should only compile into one or two extra machine instructions.
—Jens_______________________________________________
Cocoa-dev mailing list (<email_removed>)
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:
http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
This email sent to <email_removed>
| Related mails | Author | Date |
|---|---|---|
| Scott Andrew | Feb 10, 18:18 | |
| Scott Andrew | Feb 10, 18:35 | |
| Adhamh Findlay | Feb 10, 19:41 | |
| John Newlin | Feb 10, 20:13 | |
| Hans van der Meer | Feb 10, 20:20 | |
| Quincey Morris | Feb 10, 20:29 | |
| Jens Alfke | Feb 10, 20:45 | |
| Wade Tregaskis | Feb 10, 20:50 | |
| Ricky Sharp | Feb 10, 21:01 | |
| Jens Alfke | Feb 10, 22:44 | |
| Hans van der Meer | Feb 10, 23:26 | |
| Paul Bruneau | Feb 10, 23:29 | |
| Uli Kusterer | Feb 10, 23:40 | |
| Paul Bruneau | Feb 11, 00:18 | |
| Scott Andrew | Feb 11, 00:56 | |
| Quincey Morris | Feb 11, 02:32 | |
| mmalc crawford | Feb 11, 02:49 | |
| Jens Alfke | Feb 11, 03:05 | |
| Bill Bumgarner | Feb 11, 03:28 | |
| Quincey Morris | Feb 11, 04:35 | |
| Jean-Daniel Dupas | Feb 11, 10:27 | |
| Jens Alfke | Feb 11, 17:08 | |
| Ben Trumbull | Feb 11, 23:58 |






Cocoa mail archive

