Re: is protected broken, or am I?
Re: is protected broken, or am I?
- Subject: Re: is protected broken, or am I?
- From: Bill Cheeseman <email@hidden>
- Date: Mon, 14 Oct 2002 07:30:53 -0400
on 02-10-13 7:06 PM, Matt Neuburg at email@hidden 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.
I always understood this part of the documentation to refer ONLY to access
via C structures. In other words, it is about theory and the underlying
implementation details. For productive, object-oriented Objective-C
programming, I always understood the documentation to mean you shouldn't do
this, because you'll end up having to re-implement Objective-C in your
application code and you'll lose all the easy, transparent benefits of the
language. There are very few places in an Objective-C program using the
Cocoa frameworks where you need to deal directly with structures -- and most
of those have functions to eliminate even that need, like makePoint().
Looking at it again, I can see that the documentation isn't altogether clear
about this stuff. Readers' first reactions to these passages might therefore
be influenced by their programming background. I had the feeling when
reading your original posts that you were bringing the mental baggage of a
C++ programmer with you when you read it. Your reaction to the documentation
illustrates why it is often said that knowing a lot about C++ is a hindrance
when learning how to use Objective-C to its fullest advantage. As the
several answers you received suggest, you have to relax, let go of C++, and
let Objective-C's simplicity seduce you.
I also sense that you were looking for maximum efficiency in execution from
the outset. Another mistake. Use Objective-C techniques first to build your
application, then worry about optimizing it later, if you need to. If you
were to try to re-create Objective-C from the bottom up, you would never in
a million years think of the techniques that are used in the Objective-C
runtime. Because, among other things, you wouldn't think they could possibly
be efficient enough to run at acceptable speeds. But they do. I even went so
far recently as to read Brad Cox's original book. It was a little hard to
follow in places, but it was an eye-opener.
About whether the documentation is misleading or wrong. Any long-time Cocoa
developer will tell you that @private and @protected don't necessarily mean
exactly what they say to a C++ programmer. If you try to access such an
iVar, you'll get the compiler warnings or errors that will wake you up to
the implementor's intent. But Objective-C leaves an awful lot hanging out in
public if you want to resort to the available techniques to see it. It's
just that, in general, there's no need to do so, and you can't do as much
with it as you might think, anyway.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
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.