Re: OO and dynamic classes and methods...

From: <kanderso_at_BBN.COM>
Date: Fri, 03 Feb 95 11:05:29 -0500

  X-Mailer: exmh version 1.5.1 12/2/94
  To: Amancio Hasty Jr <hasty_at_netcom.com>
  Cc: stk_at_kaolin.unice.fr
  Subject: Re: OO and dynamic classes and methods...
  Mime-Version: 1.0
  Content-Type: text/plain; charset="us-ascii"
  Date: Fri, 03 Feb 1995 15:18:37 +0000
  From: Erick Gallesio <eg_at_kaolin.unice.fr>
  X-Mailing-List: <stk_at_kaolin.unice.fr> archive/latest/357
  X-Loop: stk_at_kaolin.unice.fr
  Precedence: list
  
  
> Is it possible to re-define a class and then have the respective
> instances reflect the new definition?
  
  No it is not possible and the design of STklos was explicitely done to avoid
  this. CLOS permits this but it conduct to weird situations:
  
          1. it implies that classes are not real "first class" object (in CLOS
          you have to say (make-instance 'the-class), note the quote which
          in fact permits to designate an entry in a hash table which permits
          to find the structure of the object...
          I found this was more schemish
  
I'm not sure i understand what you mean by first class. (make-instance
'the-class) seems to just be a way to look things up the class object. It
is the same as (make-instance (find-class 'the-class)). Perhaps you are
saying that classes should be able to be anonymous or lexically hidden.

          2. it costs a lot since a class must know all its instances and have a
          link over them

In the CLOS implementations this is not done with a link, but by
invalidaating the class somehow that will get detected when method dispatch
happens. It does effect performance of dispatch (if test) and slot access
(indirection).
  
          3. it complicates the semantics of slots redefinition. When you add
          or delete a slot, things are relatively clear but when you change
          some of its properties (such as its initform -- not too complicate, or
          its allocation -- more complex) things are more difficult to understand
          
          4. Most of the time, it is convenient only when develooping an
           application (it is rare that the class of an object change during
          its execution). My guess was that it would be faster to have a
          simplist system where you reload things when you see that you have
          a slot which is missing or no more useful, rather than having an
          "intelligent" system where you have to pay an overhead even if you don't
          use this feature (cause of 2, principally).
          to reload all than
  
Ideally, one should be able to use the MOP to provide these capabilities in a
"developement environment", and remove them when delivering an application.
  
Received on Fri Feb 03 1995 - 17:08:55 CET