Re: OO and dynamic classes and methods...

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

  To: Erick Gallesio <eg_at_kaolin.unice.fr>
  Cc: Amancio Hasty Jr <hasty_at_netcom.com>, stk_at_kaolin.unice.fr
  Subject: Re: OO and dynamic classes and methods...
  Date: Fri, 03 Feb 95 10:55:34 -0800
  From: hasty_at_netcom.com
  X-Mailing-List: <stk_at_kaolin.unice.fr> archive/latest/362
  X-Loop: stk_at_kaolin.unice.fr
  Precedence: list
  
   
  First and foremost we should try to make application development
  as easy as possible.
  
  I want to develop a spread sheet application development environment
  which is probably closer in concept to a GUI/application environment.
  The user should have the capability of changing classes and methods
  dynamically. One of the existing problems with window applications
  is their inflexible approach that they offer to the user.
  I believe that a user/developer should have the capability of
  changing the behavior of the programs. Besides, in a dynamic
  changing environment is kind of hard to rely on a static
  inheritance mechanism. As for the performance issue,
  if the user or application does not require dynamic inheritance
  then it should be possible to disable the feature.
  
  I really would like to understand this issue of dynamic
  inheritance vs. static inheritance specially if new languages
  such as Self, Dylan, etc... are incorporating dynamic inheritance
  into their language. For those not familiar with this issue,
  a couple of papers argue for dynamic inheritance:
  self.stanford.edu:/pub/papers/inheritance.ps.Z
                                organizing.ps.Z
  
Here are two ways to play with the dynamic inheritance (delegation) ideas
of self and other languages.

1. In a delegation language objects are a little like CLOS instances
(slots and behavior), and a little like classes since cloning is like
make-instance and adding new slots to a delegation object is like defining
a new class. Thus, if you define an object with standard-class (in CLOS)
mixed in, it will be a little like an object in Self, or Key.

2. You can delegate behavior (some or all of an object's behavior) to
another objects using multiple dispatch. So you might define a generic
function that dispatched on your parent object but would use your slots in
the method. An object would have radically different behavior simply by
changing the parent object.

k
Received on Fri Feb 03 1995 - 21:18:39 CET