Re: @protected variable access
Re: @protected variable access
- Subject: Re: @protected variable access
- From: Tim Hart <email@hidden>
- Date: Tue, 14 Sep 2004 13:27:10 -0600
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.
_______________________________________________
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