Re: subclass overwriting superclass ivar
Re: subclass overwriting superclass ivar
- Subject: Re: subclass overwriting superclass ivar
- From: Jean-Daniel Dupas <email@hidden>
- Date: Wed, 26 May 2010 15:15:47 +0200
Le 26 mai 2010 à 15:00, Roland King a écrit :
> @interface A(MyCategory)
>
> -(void)someMethodWhichLegallyAccessesThePrivateVariablePriv;
>
> @end
>
> That's legal, I can write a category against an already-compiled class without having the source and without recompiling it and I can access any of the private variables of that class. So no the compiler cannot throw away instance variables when it compiles the class originally even if no method of A used them originally because someone might go write a category against the compiled object which needs it later.
>
Note that it will not work with the 64 bit runtime, and if you declare your category in an other module than the base class one.
Using the 64 bit runtime, visibility of classes and ivars symbols is properly handled by the linker, and accessing a private ivar from an other module will result in a link time error.
That said, the compiler cannot trash ivar, whatever the code do with them, else it would change the class layout which is part of the API.
> I'm sure there are other, much simpler reasons.
>
>> Le 26 mai 2010 à 14:22, Graham Cox a écrit :
>>
>>> I'm pretty sure you are mistaken. If this were even remotely true, object programming would be impossible.
>>>
>>> @private only declares the visibility of an ivar to its subclasses, it does not give the compiler carte blanche to write over anything it fancies.
>>
>> Hmmm... Let's say you have a class A with a private variable "priv" and b a pointer to a subclass of A. Is:
>>
>> [(A *)b priv]
>>
>> legal?
>>
>> Now, admitting B never accesses any of A variables, can the compiler optimize space by throwing away all A private variables?
>>
>> Vincent
>>
>> PS: thanks for this "carte blanche" :)_______________________________________________
-- Jean-Daniel
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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 email@hidden