Re: Classes with forward-referenced supers.

[Trent Lange <lange@CS.UCLA.EDU>]

>From kanderso@DINO.BBN.COM Wed Jan 31 09:25:41 1990
>To: Trent Lange <lange@cs.ucla.edu>
>Cc: commonloops.pa@xerox.com
>Subject: Re: Classes with forward-referenced supers. 
>In-Reply-To: Your message of Tue, 30 Jan 90 22:57:52 -0800.
>             <900131.065752z.17041.lange@lanai.cs.ucla.edu> 
>Date: Wed, 31 Jan 90 10:47:12 -0500
>From: kanderso@DINO.BBN.COM
>
>
>  Redistributed: commonloops.pa
>  Date: Tue, 30 Jan 90 22:57:52 PST
>  From: Trent Lange <lange@cs.ucla.edu>
>  To: commonloops.pa@xerox.com
>  Subject: Classes with forward-referenced supers.
>  
>  
>  What is the official word on making instances when a class has
>  forward-referenced super-classes?
>  
>  It seems to me that making instances of classes with forward-referenced
>  supers definitely *should* be legal, simply creating an instance that
>  is minus the features of those forward-referenced classes.  When the
>  forward-referenced supers are actually defined, of course, PCL 
>  would then have to update any previously created instances, but this is
>  no different than when the class itself is redefined.
>  
>  On the other hand, it seems *quite* important to be able to make instances
>  when all of the super-classes are not yet defined.  Applying
>  class-prototypes comes directly to mind, plus defining classes with lists
>  of possible super-class mixins, which either may or may not be used
>  depending upon whether a user wants to load them or not.
>  
>I think your proposal is interesting.  However, if you could create an
>instance of a forward referenced class, you would loose the protection
>that the current PCL provides.  There would be no way to stop the use
>from making instances when some important behavior was still missing.
>If he never intends to use a set of mixins, redefining the class is
>about as easy as not loading the file containing the mixins.
>
>k

Of course, generally one would want to have defined all of the
mixins before making instances, as is done now.

However, I can easily envisage large packages developed in CLOS
(such as the connectionist simulator we're now developing) in which
one could explicitly tell a naive, non-CLOS user the capabilities
that loading each file (and thus forward-referenced mixins) will
give to his "objects".  These kinds of instructions would be
very clear to such a user, and would provide flexibility
to load only necessary files/mixins, which would be especially
important for very large packages running on small computers.  It
would also give a simple way for a user to purposefully exclude
behaviors that are not wanted.

The alternative is, as you said, making the user redefine the
classes.  This is no problem for the package's developer,
but could be quite confusing for naive non-CLOS users.  After
all, in addition to learning the basics of object-oriented
programming and how to define classes in CLOS, they would
have to know the behaviors of each of the mixins in the package
and which ones to combine to give their objects the desired
capabilities.

The legal forward-referenced class option thus seems much
simpler for naive users of large packages that have many
behavior options.  The result of trying to use a behavior
of a forward-referenced mixin that has not yet been "loaded"
is clearly defined, being simply an error.

Of course, I don't know if this is a point that has already been
debated in creation of the specifications.  If not, it might
be an interesting question to discuss.

- Trent Lange