Re: is protected broken, or am I?
Re: is protected broken, or am I?
- Subject: Re: is protected broken, or am I?
- From: Mike Shields <email@hidden>
- Date: Wed, 23 Oct 2002 20:19:15 -0600
This is subtle:
// Assuming you have written a class similar to the Sibling class in
the ObjC programming book.
@interface Sister : Sibling
@end
@implementation Sister
// This method DOES compile as you'd expect it to using the rules of
inheritance
// and assuming that it's the same as makePrettyFraternalSister being a
method of Sibling.
- makePrettyFraternalSister
{
Sister* sister = [[Sister alloc] init];
sister->gender = 1;
sister->isUgly = NO;
return sister;
}
// This method DOES NOT compile.
- makeUglyFraternalSister
{
Sibling* sister = [[Sister alloc] init];
sister->gender = 1;
sister->isUgly = YES;
return sister;
}
@end
So it looks like it treats a statically typed Sibling* object in the
scope of the Sister class as if it was a completely different object
type, say a Parent.
But if the object it typed as a Sister in the scope of the Sister
class, then everything works as you'd expect it to.
I'm not sure if this is actually a bug or if it's a result of an
implementation detail (like "Class of object I'm trying to access ==
Class of self" and not "I'm a type of Class").
Mike
On Wednesday, October 23, 2002, at 07:08 PM, matt neuburg wrote:
On Tue, 22 Oct 2002 09:01:52 -0700, Dennis De Mars
<email@hidden> said:
On Sunday, October 13, 2002, at 04:06 PM, Matt Neuburg wrote:
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?)
My quotations come from this file:
.../ObjectiveC/3objc_language_overview/Defining_a_Class.html
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 that is the rule, then that is not at all what the docs say, as far
as I can tell. 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.
_______________________________________________
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.