Re: @protected variable access
Re: @protected variable access
- Subject: Re: @protected variable access
- From: Matt Neuburg <email@hidden>
- Date: Tue, 14 Sep 2004 15:52:48 -0700
Actually if you want to override protection for a particular ivar, safely
and easily, you can use key-value coding:
[theFoo valueForKey: @"ivar"]
So this makes the whole matter pretty much moot (and makes the whole
cast-to-a-struct hack completely unnecessary).
However, the purpose of @private and @protected is to get the compiler to
complain when the programmer tries to access a member he isn't supposed to
access. That being the case, I just don't buy the argument that the downcast
idea is bad. On the contrary, it's good because it recognizes the protection
that @protected is there to protect, and bargains with the compiler ("Yes,
compiler, I'm not supposed to see this ivar, but trust me, it's okay, and
here's why"). Your struct hack, and key-value coding, just bypass the
compiler's protections completely, making their use pointlesss. m.
On Tue, 14 Sep 2004 13:27:10 -0600, Tim Hart <email@hidden> said:
>
> On Tuesday, September 14, 2004, at 12:41PM, Matt Neuburg <email@hidden>
> wrote:
>
>> I don't know that I see this as a problem. I was not suggesting that you
>> downcast permanently - just for that one statement where you want to access a
>> protected superclass ivar.
>>
> It's really a personal thing. Dunno how often it happens in the real world at
> large, but I've been bitten a few times by casts that weren't accurate. Some
> maintainer later on reads the code and assumes it's a safe cast in general, or
> that you can always be sure that the type being passed in is the type being
> cast. So they access some other ivar that's a part of the subclass, and things
> begin to go bump in the night. Comments do help, but comments don't generate
> compiler errors.
>
> Anyway - as a result of my personal history I tend to avoid casts that aren't
> accurate.
>
>> But that works for private ivars too, from any class (not just a subclass),
>> so essentially you're just throwing public / private / protected out the
>> window.
>>
> True. I was really posting the option to help make the topic complete on the
> list. Each solution has its merits and drawbacks.
>
>> If you're going to do that, why not declare all your ivars public and just
>> program by contract? Or to put it another way, if this counts as a solution
>> for you, why bother using @protected to begin with? m.
>>
> Agreed, it's a hack. I just thought it to be the slightly lesser of two evils
> -> incorrect cast vs stripping ivar protection. The goal in my case was to
> strip ivar protection for that variable. Future maintainers would probably
> still consider it bad code, but they'd be less likely to access something that
> wasn't there. Were I to implore it, I was also add 'HACKTAG' comments, and
> only use the cast very judiciously - hopefully only once.
>
> I agree also that my arguments above are weak - as are all arguments
> for/against hacks. I in no way intended to promote mine as 'absolutely
> superior'. Simply that I preferred it and why.
>
>Another solution in my case would have been to so something like this:
>
>-(id)initWithFoo:(Foo*)foo
>{
> [super initWithFoo:foo];//a *realy* copy constructor, instead of a
quasi-copy constructor
> //do my unique stuff here
>}
>
> Implement initWithFoo *in* Foo - no issues with accessing one protected ivar
> from another instance of the same class, so no worries. No hacks of any kind.
>
> But I was code-blind for a bit. Kinda obvious (and embarrasing) now, though.
> Regardless, none of the above solutions work for me for issues completely
> outside the scope of this subject.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide
<http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt>
_______________________________________________
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