[1237] in Coldmud discussion meeting

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

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>

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

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,


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). 
>        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.
>-Brandon Gillespie