[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Classes with forward-referenced supers.
- To: lange@CS.UCLA.EDU
- Subject: Re: Classes with forward-referenced supers.
- From: Danny Bobrow <email@example.com>
- Date: Thu, 1 Feb 90 10:56 PST
- Cc: commonloops.pa@Xerox.COM
- In-reply-to: <firstname.lastname@example.org>
- Redistributed: commonloops.pa
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
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.
- Trent Lange
The simple solution for the developer of a package is simply to define
as empty classes the full set of classes that may possibly exist for the
application. No forward referenced classes are needed. When a naive
user then loads a particular file, the class gets redefined. This is
identical to what you proposed above, with the exception that the
package developer must provide two definitions for optional classes --
the empty one, and then the package one. These leaves the protection
in place for forward referenced classes, and the ease of use for naive users.