[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Instance Variables: "private" vs "protected"
- To: <son-of-blob!eric@xxxxxxxxxxx>, <dean@xxxxxxxxxxx>
- Subject: Instance Variables: "private" vs "protected"
- From: Mark S. Miller <vlad!mark>
- Date: Thu, 5 Jul 90 12:36:05 PDT
- Cc: <xtech@xxxxxxxxxxx>
- In-reply-to: <xanadu!son-of-blob!eric's>,20 PDT <9007041918.AA13445@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 4 Jul 90 12:18:20 PDT
(Wearing my "make other people's smalltalk code work in C++ hat"):
I'm all in favor of having member variables be private everywhere
IFF people programming in smalltalk can guarantee that they'll program
It sounds like we're all willing to guarantee this (soon but not
immediately), given that we arrange to have the C++ compiler tell us
when we've made this error.
The translator generates PROTECTED/COPY/SELF_COPY, the later
two being protected currently, because that reflects the semantics of
smalltalk. In fact what forced COPY and SELF_COPY to be changed to
protected was that the first code translated with (SELF_)COPY did not
compile because routines routinely used inherited member variables.
My bottom line: "Minimize semantic differences between our languages"
In this sense, I'm suggesting that it's proper for us to define the
X++ language as being more restrictive that either Smalltalk or C++
(but clearly compatable with both). However, as with type-checking,
other visibility contraints, and missing code, this new X++ language
contraint doesn't get enforced until you try to compile your
translated code. Thus while doing fast prototyping (when the code is
evolving quickly) we aren't stopped by such problems. But once it
settles we use the C++ compiler to debug away these problems. In all
these regards, this new visibility constraint would be treated exactly
the way we already handle private classes.
Date: Thu, 5 Jul 90 10:58:27 PDT
From: xanadu!tribble (Eric Dean Tribble)
I think I agree in general, but could you point at some examples? As
I recall I use some protected members in the ent stuff that I'd really
rather not change any time soon.
I actually expect that many of the bad examples are in my own code.
The point is that the best way to find these cases is to change the
translator and the tofu macros (see above) so that all data is once
again private. Then the C++ compiler will tell us where the examples