In article <··········@world.std.com>,
Tony J. Kanawati <·····@world.std.com> wrote:
>Rainer Blome (······@physik3.gwdg.de) wrote:
>: ...
>: To me, the protoypes-and-messages model seems much better suited to the usual
>: programming tasks than the usual classes and generic functions as with
>: CLOS and the like (they aren't the same, I know that).
>
>Prototypical objects are more suitable for some tasks, but they don't very
>little static information, and their behavior changes dynamically. This
>raises the level of program comprehension complexity to new level, and can
>severely complicate debugging and maintenance.
>
>But, I agree, it is fun to program in such a paradigm [excuse the cliche].
>--
Luke Tierney's Xlisp-stat - a statictical programming package built on
Xlisp - has a prototype-based object system. Xlisp, itself, uses a
class based object system. Xlisp is not a Common Lisp implementation,
but with a set of common lisp compatible functions loaded, it is
reasonably close enough - except that neither object system (vanilla-Xlisp
or Xlisp-Stat) is anything close to CLOS. This was initially somewhat
troubling to me - investing time in learning such a non-standard
system. However - quoting from a review in Statistical Science (Nov 91)
by Forest W. Young :
| "[ ... ] Tierney has developed his own prototype-based object system,
| a system that does not correspond, even philosiphically, to CLOS, the
| standard Lisp object system. While this may be a problem for Lisp
| afficionados, the reasons given by Tierney for the nature of his
| object system stem from the observation that statistical programming
| is "experimental programming", and from his (among others) colclusions
| that a prototype-based system is more appropriate for this type of
| programming."
After using it for a while - I'm not sure I understand exactly what
Tierney may have meant about prototypes being more appropriate for
experimental programming - but I have seen a few examples that lead me
to accept that it may be more appropriate for programming interactive
statistics and graphics. In particular - I often find it's useful to
create derived data sets. For example: I have a prototype template for
a spectrum - which could just as well be encapsulated in a class.
However, a "bandpass-filtered-spectrum" or other derived data like a
vector of inverse variances used for multiple-least squares fitting,
seems to be easier to deal with, and conceptually make more sense, as
being a child of a specific "parent" spectrum, and not as another
sub-class of Spectrum. (The derived data set shares more slots, and
has more in common with it's parent spectrum/data-set than with any
other derived data set of the same "type" or sub-class. ) Perhaps
where this fits in with Tierney's comments about experimental
programming is that there is no end to (subclasses of) derived data -
and with a prototype system, you never have to "go back to the drawing
board" to invent another class and figure out where it belongs in the
class hierarchy. A prototype-based system can ( if you start off with
a logical design ) extend itself logically and automatically.
Perhaps the dichotomy between class-based and prototype-based object
systems and "experimantal programming" or rapid-prototyping is similar
to the one between statically typed compiled languages and dynamically
typed interpreted languages.
---| Steven D. Majewski (804-982-0831) <·····@Virginia.EDU> |---
---| Computer Systems Engineer University of Virginia |---
---| Department of Molecular Physiology and Biological Physics |---
---| Box 449 Health Science Center Charlottesville,VA 22908 |---