Re: is protected broken, or am I?
Re: is protected broken, or am I?
- Subject: Re: is protected broken, or am I?
- From: Dennis De Mars <email@hidden>
- Date: Tue, 22 Oct 2002 09:01:52 -0700
On Sunday, October 13, 2002, at 04:06 PM, Matt Neuburg wrote:
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.
You know, I think they might have changed this. I'm pretty sure I saw
this addressed explicitly in the Obj-C manual and it was supposed to
have worked as you outlined. But referring to the current edition from
Apple (May 2002) I can no longer find this. (Which docs are you
referring to?) And obviously, the compiler is now enforcing this.
Personally, I think the original interpretation was sufficient. The
original idea was for the code _implementor_ (i.e. the human writing
the code) to be able to control access to the instance variables from
implementors writing code for subclasses or unrelated classes, so that
it could be assumed the variables are in a consistent state; not that
the variables should be protected from individual _instances_ of the
class.
However, most people have always thought that is the way it worked, so
maybe they just decided to start enforcing that. It seems to me,
though, that in this case @protected is being treated in an
inconsistent manner as opposed to @private and @public. If an ivar is
@public it can be accessed by other objects, and if it is @private it
can be accessed by other objects (as long as they are of the same
class). You might be surprised at this but try it!. But if it is
@protected, suddenly this special rule cuts in where other objects of
the same class can access the ivar, but if it is a subclass only the
object itself can access it. If this is reasonable for @protected, why
not extend the rule to @private?
- Dennis D.
_______________________________________________
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.