[1238] 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 15:39:07 1997 )

Date: Sat, 1 Mar 1997 12:28:54 -0700 (MST)
From: Brandon Gillespie <brandon@cold.org>
To: Jeff Kesselman <jeffk@tenetwork.com>
cc: coldstuff@cold.org
In-Reply-To: <>

On Sat, 1 Mar 1997, Jeff Kesselman wrote:
> 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
> 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,

But this isn't breaking the encapsulation--it is simply changing the
default value when a specific instance is not defined.  The variable still
can only be assigned-to/referenced by the defining object.  For a better
explanation I'll give the example given to me:

$thing has:

derived is a $knife, which changes weight, mass and integrity for a
generic sword, and adds a 'sharpness'.

If you want a specific instance of a knife you have to basically reset all
of the $thing values to be the same as $knife--when it'd be easier just to
make it a public variable (i.e. the 'default' value is that of the first
instance in the ancestor tree)--and only change what you care about.

-Brandon Gillespie