Re: @protected variable access
Re: @protected variable access
- Subject: Re: @protected variable access
- From: Tim Hart <email@hidden>
- Date: Mon, 13 Sep 2004 14:43:33 -0500
On Sep 13, 2004, at 2:28 PM, Tim Hart wrote:
On Sep 12, 2004, at 4:56 AM, Ondra Cada wrote:
Of course it is *not* legal, neither would it be even without
subclassing in a Foo method. You are accessing the property i from
the *outside* here: the property you are trying to access is not part
of self! To be allowed to do that, it would have to be declared
@public.
Not true. Consider this
@interface Baz
{
@private
int j;
}
//...
@end
@implementation Baz
-(BOOL) isEqual:(id)other
{
BOOL result = NO;
if(self == other){
result = YES;
}
else if( [other isKindOfClass:[ self class]]){
Baz *otherBaz = other;
result = j == other->j; //perfectly legal. The compiler does not
complain, and this access is outside the class
oops. That's..
result = j == otherBaz->j;
}
}
@end
What you really want to is to use a proper encapsulation through an
accessor
No, that is exactly what I do not want to do. The ivar being accessed
is not intended to be accessible or known about to the 'outside
world.' It has no business meaning by itself. It exists to support
other domain related functionality. While I could 'warn' someone that
the variable in question is 'for internal use only', I would rather
make the compiler complain about illegal access (ironically, exactly
like the compiler was doing to me!).
Note that it is very right to do so; if you did that the Java/C++
way, you'd be hang dry as soon as there is a subclass which
reimplements the foo's notion of 'i' in its own way.
For the record, I was incorrect about Java and C++'s behavior. in C++
such access is illegal. In Java, it's legal to access protected
members of any class in the same package. My particular example would
have failed if the classes were defined in different packages.
I'm aware of that possibility that another subclass of Foo might
reimplement 'i'. In this implementation it is so severely remote as to
be effectively zero. If I were concerned about someone redefining 'i',
I would have marked it @private in the first place.
I am also aware of the risk of assuming that Bar knows about the
intent of Foo.i. That is a calculated risk that I accept. I am the
author and maintainer of both Foo and Bar. Neither class is intended
to be subclassed by anyone but me. There is a chance that the outside
world will never see these classes.
(Just for completeness: yup, there are very rare cases when the
accessors might be unacceptable due to the application speed: nearly
always it means you should re-factor your code :)
Speed is not my concern here. I do not want to imply usefulness of my
ivar to the outside world by providing an accessor.
And yup, it does mean @protected is not really useable in 99.99% of
situations and we should use @private instead. And that means
GCC/ObjC, unlike Java/C++, does it almost right: completely right it
would be if @private were the default.)
And here we differ. This is a religious war that's been fought for
years. Not going to argue about that now. My question was on rules of
the language, not philosophy.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden