Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!ginosko!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.lang.lisp
Subject: Re: CLOS: is it OOP?
Message-ID: <1989Sep16.220048.22688@odi.com>
Date: 16 Sep 89 22:00:48 GMT
References: <19582@mimsy.UUCP> <29564@news.Think.COM>
Reply-To: dlw@odi.com
Distribution: usa
Organization: Object Design, Inc.
Lines: 15
In-reply-to: barmar@think.COM's message of 15 Sep 89 21:11:35 GMT

In article <29564@news.Think.COM> barmar@think.COM (Barry Margolin) writes:

   I'm also a fan of encapsulation and protection, but I don't think that
   they are absolutely required for an object system.  CLOS probably
   lacks them mostly because Flavors lacks them, and Flavors probably was
   copying DEFSTRUCT-style inheritance.  It could also be the general
   Lisp philosophy of allowing the programmer as much freedom as
   possible.  DLW, do you know why HIC implemented Flavors this way?

I would say that Flavors *did* have "encapsultation and protection".
In the original Flavors, instance variables by default are NOT
"gettable", "settable", or "initable".  This means that the only code
that can access them is code inside methods.  If that's not
"encapsultation and protection", I'm not sure what is; if you had
something specific in mind, what was it?