🚀 go-pugleaf

  To: comp.lang.clos@cis.ohio-state.edu
  Date: Wed, 2 Sep 1992 11:58:45 GMT
  Organization: School of Mathematics and Statistics, University of Sydney
  From: Graham Matthews <graham@maths.su.oz.au>
  Sender: commonloops-request@cis.ohio-state.edu
  Subject: Implementation Question
  
  I was wondering about a small implementation problem I am having.
  Imagine I have two classes A and B defined as follows,
  
  	class A
  		instance variables a, b, c;
  	end class;
  
  	class B
  		subclass of class A;
  		instance variables e, f;
  	end class;
  
  (by "instance variable" i mean that an instance of class A will
  have three "fields"/"slots" (pick your terminology!) named a, b and
  c).
  
  Now my problem is as follows. How do OO implentations handle the 
  space allocation for an instance of class B? Does an instance of B
  have to have space allocated for all the instance variables in B as 
  well as all the instance variables in all the classes of which B is 
  a sub-class (in this case class A). I ask this for three reasons :-
  
Generally, in classed based OOP, like Smalltalk, Lisp, and C++, a B gets all
of an A's slots.  In a delegation based language like Self, a B can have a
prototypical A as a parent.  A B would then get its A's behavior without a
copy of its slots.  In a classed based language you can simulate such
delegation. 

  a) I have many examples where B is a subclass of A but one rarely
  utilises this feature. All the time is spent computing with instances
  of B as instances of the sub-class B and not as instances of the 
  super-class A. So I do not want to allocate space for any instance 
  variables (in this case those in class A) which I am rarely if ever 
  going to use.

But there must be some A behavior that B needs, otherwise B would not need
to be a subclass of A.  It sounds like you want your B class to inherit
from a class "essential A" which has the A behavior you need, without the slots.
  
  b) I have example code where the representation of B is not the
  same as A. That is mathematically B is a sub-type of A but for
  various reasons the implementation of B does not have any of the 
  slots of A.
  
You can separate the "mathematical subtypeness" from implementation using a
level of indirection:

class A
       instance variables implementation;
end class;

class B
       subclass of A;
end class;

A's and B's can forward to an object in instance variable implementation
that implements the real behavior.

  I can think of one solution using associative arrays, but this must
  be a standard problem with a set of standard solutions.

I presume someone more theoretical than i could argue that the notion of
inheritance in current OOP languages is too crude to correctly handle all
the issues involved in sharing state, behavior, and typeness.