[829] in Coldmud discussion meeting
Re: protected and private object variables
daemon@ATHENA.MIT.EDU (Sun Oct 15 21:15:47 1995
)
Date: Sun, 15 Oct 1995 21:06:54 -0400 (EDT)
From: James C Deikun <jcdst10+@pitt.edu>
In-reply-to: <9510152250.AA08315@smithfield.declab.usu.edu>
To: 869683 Gillespie Brandon James <brandon@smithfield.declab.usu.edu>
Cc: coldstuff@pippin.ece.usu.edu
Reply-to: James C Deikun <jcdst10+@pitt.edu>
On Sun, 15 Oct 1995, 869683 Gillespie Brandon James wrote:
> < They should be 'instance' and 'class' variables, or'child' and 'definer'
> < variables if you want to be obnoxiously classless.
>
> The concept is the same, the name is an important detail, but there is
> no _should_ or _shouldn't_, other than if I'm trying to emulate another
> language, or what my desires are in creating this functionality.
Hm, maybe 'wrong' was the wrong word. (Well, an ill-advised one.)
What I was trying and apparently failing to express with the word wrong
was "confusing for beginning programmers starting out with ColdC,
confusing for programmers familiar with object-oriented languages,
and confusing for experienced programmers starting out with OO languages
with ColdC."
> I have intentionally shied away from using instance and class for a
> few reasons, mainly that there ARE NOT instances and classes, and using
> such names would be horribly misleading.
Well, you have a point.
> With this in mind, I decided 'private' was good, because it essentially
> functions like the 'private' flag on a method (i.e. only if caller() is
> definer() can it be executed). 'protected' just sortof fell into place
> after that.
I'm not sure in what way this functions like the private flag. "Private"
for a method means it is accessible only from methods defined on its own
definer. All variables fit this definition of "private." A 'protected"
variable I would expect to be accessible from methods defined on children of
its definer, as are protected methods.
It seems like the feature you've suggested introduces a difference along
a totally different axis, while keeping all variables 'private' as they
were before. This is what I meant by 'wrong', basically--the names of
features already in ColdMUD (as well as the English meanings of the terms
you've suggested) make your suggested terms for this feature extremely
misleading.
> Mind you, I like the suggestions, it was just the sternminded 'you are
> doing it _wrong_' that I dont like. Frankly, the way it is finally
> implemented is the right way (period) even if it isn't like what others
> do, because its how I've decided to do it, after considering all influences
> I could. Hmm, basically: I dont care if thats "how the Jones do it", its
> all ones and zeros in the end ;)
Well, I'll try to write messages somewhat more like this one and less like
the last one in the future.
> I'll brainstorm names here. First, we have variables which are restricted
> to the defining object, and cannot be redefined on a descendant. Then you
> have the regular variables, which CAN be redefined. The first name will
> always be in reference to the !redefinable variables:
>
> definer (your suggestion)
> child (your suggestion)
>
> private (mine)
> protected (mine)
>
Already discussed.
> limited
> regular
These terms seem rather vague, and I don't understand how being stored
only on the parent object rather than on each descendant is well
described by terms such as 'limited'.
>
> restricted
> normal
These too.
> private
> normal
These still contain what seems to me a misleading use of 'private'.
definer
descendant
shared (Eric Weber's suggestion)
unshared
shared
individual
--
James "just for the halibut" Deikun
the fender of justice * writer of wrongs * keeper of the very important frog
************* I said, "We need more gate_d_s on the Internet!" *************