Re: Confused about superclass initializers
and if I'm a moron and subclass a Foo which is ... singleton or
returns one specific instance for its parameters then .. I get some
cached Foo and it's my own stupid fault.
[ self alloc ] makes sense .. most 'bait and switch' initializers
would call that, and of course that goes back to the subclass again.
On Mar 27, 2009, at 11:05 PM, Alexander Spohr wrote:
Am 27.03.2009 um 15:53 schrieb Roland King:
I've thought myself into a hole in a subclass here ....
If I have a class Foo with a subclass Bar, which adds say 2 new
variables, in Bar's init method I do the usual
self = [ super init ];
after someone called me with
Bar *myBar = [ [ Bar alloc ] init ];
at the point I call that, 'self' is a Bar, it was alloc()ed to be
long enough for a Bar. But it's quite possible that Foo's init will
not init the object it's given, it will throw it away and return me
a totally different Foo, [ super init ] doesn't have to return the
same thing you sent it. But if that happens, it will be a Foo
returned, it won't be a Bar, Foo's constructor has no idea that
it's really meant to be making a Bar, it won't have enough memory
allocated to be a Bar.
Then bad things will happen when I try to set the Bar variables as
I don't have enough memory for it.
Good thought :)
But this ist Objective-C, so a good class does not call [Foo alloc]
but [self alloc] if it is going to allocate some new instance of
itself. And even if you call [super init] (at which time self is an
instance) your self in the class-methods will stay Bar.
The only problem for Foo is, that it won’t know the designated init
But usually you get almost never something else back from super init.
Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx)
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 maillists@xxxxxxxxx