[1237] in Coldmud discussion meeting
Re: [COLD] public/private/protected object variables
daemon@ATHENA.MIT.EDU (Sat Mar 1 13:34:06 1997
)
Date: Sat, 01 Mar 1997 10:34:10 -0800
To: Brandon Gillespie <brandon@cold.org>, coldstuff@cold.org
From: Jeff Kesselman <jeffk@tenetwork.com>
Um,
My comment is you convinced me quite awhile back that absolute
incapsulation is a good thing.
I've never found the real need to break it, there was always a reasonable
encapsulated alternative... the ONLy time i thought itw as trouble was that
members couldn't be accessed easily for modification external debugging
tools... whiel that still MIGHT be an issue, I certainly foudn on
retrospect perfectly resonable ways to do what I was trying to do with
MUDEDIT.
I guess I'ld have to say I think its a bad ideas. I think its dilutes the
strengths of COldC-- oen of which is that it breaks your sloppy C++ habits
and FORCES yo uto learn how to write really good object orinted code.
Opinionated as always,
JK
At 09:09 PM 2/28/97 -0700, Brandon Gillespie wrote:
>Back when I added public/private/protected methods I considered diong the
>same with variables. Once again I'm considering it--simply because the
>need for such a beast is more and more becoming a need for some people.
>What I'm thinking of implementing is three types of object variables. We
>would still keep encapsulation in that only the definer can access
>variables and instances it defines. What we would be expanding on is the
>default value for these instances (i.e. what is inherited and how).
>Basically:
>
> private -- act as they do now--if no instance is defined
> simply return zero. This would be the default
> protected -- if there is no instance, use the _definers_
> instance (and only the definers)
> public -- get the first instance in the ancestor tree--using
> the same search requirements as for methods. We
> would likely want a cache like with methods..or not.
>
>Comments?
>
>-Brandon Gillespie
>
>