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:24:09 +0200
Le 26 mai 2010 à 15:10, vincent habchi a écrit :
> Le 26 mai 2010 à 14:53, Graham Cox a écrit :
>
>>
>> On 26/05/2010, at 10:41 PM, vincent habchi wrote:
>>
>>> 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?
>>
>>
>> No. It's not legal syntax for accessing an ivar in any case - square brackets invoke a method:- [instance method].
>
> Granted. I assumed there was a getter defined. That's because, AFAIC, I almost always synthesize ivars, so they become regular attributes.
>
>> Perhaps you could ask is:
>>
>> (A*)b->priv legal?
>
> Yes. Indeed.
>
>> Depends. If priv is @private it is invisible to code other than within the methods of class A itself, so if this code lived inside such a method it would work, otherwise it would not. I don't think the cast makes any difference.
>
> So, tell me if I'm wrong, but I infer from your answer that whatever I can do, there is no means for a subclass A' to access any private variable of its ancestor.
>
>> But this is not getting to the problem that the OP is having, which AFAICS is unrelated to @private. @private is a Good Thing™ - often worth using.
>
> Well, as a regular Python code writer, I've never missed @private (or even @protected) declarations. I fail anyhow to grasp the relevancy of @private vis-à-vis @protected: It seems logical to me that subclasses be granted access to all ancestor attributes.
Why a subclass should have more right to mess up with private ivar than an external class ?
Who knows what a class does when you set an ivar using the accessor. It would badly break encapsulation principle.
For example, what would append if a NSView subclass change the view frame by accessing the _frame ivar directly ?
-- 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