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: Thu, 24 Oct 2002 08:42:10 -0400
on 02-10-23 9:08 PM, matt neuburg at email@hidden wrote:
>
> 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.
Your misunderstanding of the documentation comes from assuming that the
method you quoted above anticipates the later passage about the role of the
@protected directive. You are quite explicit about the fact that you are
making this assumption: you say that "this [method] is *presumably* in
accordance with the definition of 'protected' that appears on the next page"
(emphasis added).
I submit that your "presumption" is incorrect. This portion of the book is
not a reference (the reference portion comes at the end), but is instead a
vehicle for teaching the subject. As such, it necessarily introduces
concepts one at a time.
The way I read this chapter is this: First, the makeIdenticalTwin method is
given as an example of the concept of an iVar's "scope" from a broad,
structural viewpoint. That is, all of a class's iVars are in the class.
Second, once I understand this broad, structural concept of "scope," the
passage on the next page introduces new information, explaining how
limitations on "visibility" work. In explaining this, the passage redefines
the initial concept of "scope" to include not just a structural notion, but
also an additional notion of definable "visibility." In other words,
although a "protected" iVar is in-scope in the first, purely structural
sense, it is not visible (i.e., not in-scope in the new, more refined sense
of "scope") outside the inheritance structure of a specific object.
Thus, the example you quote above assumes that "twin" is declared @public,
not that it is declared @protected. This assumption is reasonable from a
didactic viewpoint at this stage of the text, since the idea of limited
visibility of in-scope iVars hasn't yet been broached. The reader doesn't
yet know that an in-scope iVar might have its visibility limited, so the
first-time reader's natural assumption is that scope implies unlimited
visibility. It is only by "reading ahead" and then going back to the initial
passage that your misunderstanding arose.
I believe the "Defining a Class" chapter lays this out fairly clearly if you
read it in a linear fashion. After explaining the syntactical rules for
declaring interface and implementation and explaining something about the
concept of inheritance, it follows up with a subsection entitled "Referring
to Instance Variables." Here, you are told, "By default, the definition of
an instance method has all the instance variables of the
object within its scope. It can refer to them simply by name. Although the
compiler creates the equivalent of C structures to store instance variables,
the exact nature of the structure is hidden." Then, with this "default"
structure of the language explained, it turns to the next section, entitled
"The Scope of Instance Variables." Following some introductory discussion of
the need to hide data and the preference for using accessor methods over
iVars in the actual "implemenation" of the concept, you learn that "To
enforce the ability of an object to hide its data, the compiler limits the
scope of instance variables that is, limits their visibility within the
program. But to provide flexibility, it also lets you explicitly set the
scope at three different levels." So, now you know that the initial
description of the concept was broadly stated, but that the implementation
of it in the language is more limited -- or can be, unless you explicitly
declare an iVar to be @public.
Now, any text can be improved with editing. I have no doubt that this
chapter's progression from broad concept to narrower, qualified
implementation could be revised to make it clearer on second reading. As a
lawyer, I spent several decades fine tuning the way I presented legal
arguments to judges so as to help them understand my argument both the first
time they read a brief and the second time they read it. There are several
available devices: for example, you can have a brief "executive summary"
that summarizes the argument about to be made, or you can have a brief
"conclusion" that wraps it up, or you can insert footnotes saying "watch
out, there are qualifications coming that will limit what I'm saying now."
The one thing you can't do is to say it all on the first page.
--
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.