[829] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

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!" *************