Re: is protected broken, or am I?
Re: is protected broken, or am I?
- Subject: Re: is protected broken, or am I?
- From: Matt Neuburg <email@hidden>
- Date: Sun, 13 Oct 2002 16:06:53 -0700
On Thu, 10 Oct 2002 18:20:42 -0400, Bill Cheeseman
<email@hidden> said:
>
>
on 02-10-10 5:24 PM, matt neuburg at email@hidden wrote:
>
>
> But on other occasions when this window appears it behaves quite a different
>
> way. I don't want to put the code for this alternate behavior into MyClass.
>
> I'd like to put it into some other class and have an instance of that other
>
> class step into MyClass's coat, as it were, taking on all the outlets, and
>
> being pointed to by all the window stuff, that the MyClass instance
>
>already is
>
> set up with in the nib.
>
>
>
> This is why I thought of a subclass of MyClass.
>
>
Why doesn't an instance of the subclass load (a copy of) the same nib,
>
making itself the file's owner in the process? The nib will be unarchived
>
into the instance of the subclass, and all the nib's outlets, actions, and
>
connections will be wired up to the (protected, and therefore accessible)
>
iVars (in that very instance) that the subclass inherits from its super.
Exactly so - this was suggested to me offline by Erik Buck, I tried it, and
it turns out to be precisely the desired solution. Many thanks.
>
In trying to access iVars in a separate instance of the superclass, you're
>
talking to a stranger.
I still think that either the documentation is wrong or that "protected"
isn't working the way it should. The documentation uses an example where a
Sibling method runs as follows:
- makeIdenticalTwin {
if ( !twin ) {
twin = [[Sibling alloc] init];
twin->gender = gender;
twin->appearance = appearance;
}
return twin;
}
The implication is that one Sibling instance can indeed reach right inside
another Sibling instance and access its copy of the instance variables; the
code can refer to twin->gender as glibly as it refers to self->gender.
Since there is no @public declaration in the interface code which appears
just before, this is presumably in accordance with the definition of
"protected" that appears on the next page: "The instance variable is
accessible within the class that declares it and within classes that
inherit it."
Well, then, if a Sibling instance can see the ivars of a separate Sibling
instance, but a Sibling subclass instance cannot see the ivars of a
separate Sibling instance, then either protected is not working as
advertised, or else the phrase "the instance variable is accessible within"
is being equivocated upon (for the two difference cases) in a way that
makes the sentence almost meaningless.
On Fri, 11 Oct 2002 11:39:16 -0400, Brent Gulanowski <email@hidden> said:
>
The central idea of objects is that they cannot get into each others'
>
ivars, even if they are of the exact same class.
If that's true, then the above-quoted code from the docs is wrong.
m.
--
matt neuburg, phd = email@hidden,
http://www.tidbits.com/matt
pantes anthropoi tou eidenai oregontai phusei
Subscribe to TidBITS! It's free and smart.
http://www.tidbits.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.