From: David Bakhash
Subject: Re: How make an abstract class in CLOS?
Date:
Message-ID: <m33dn89tfo.fsf@alum.mit.edu>
the real question here is "why do you think you need an abstract class
in common lisp, and what do you think it would get you?"
I programmed in CLOS for a long time before I ever considered this
abtract class notion. I think the better thing to do with CLOS is to
literally forget what you know from other object systems (especially
Java, which only confused me, and troubled me in its limitations).
don't worry about finding analogous terms and constructs to what you
already know. The reason is that while some points in CLOS are indeed
subtle, and some are complicated, and there are several steps one must
know about, CLOS on a whole is not too bad. you can do most things
quite easily. In fact, the macro DEFCLASS does so much, surprisingly,
that you hardly have to think.
If you get caught trying to find rigorous analogies between CLOS and
(say) Java's object system, then you'll be troubled because in Java
(and C++), methods belong (and I think are lexically defined) inside
the classes to which they apply. Since methods belong to a paticular
class, they can't dispatch based on multiple classes (at least not
without ugly CASE-like statments or something). Furthermore, Java's
single-inheritance-plus-interfaces hack is different from CLOS's
multiple inheritance. then, with method combination and other things,
you just start to realize that it's best to drop what you know and try
learning CLOS with an open mind. Then I think that the most important
90% or so is fairly easy.
dave
In article <··············@alum.mit.edu>,
David Bakhash <·····@alum.mit.edu> wrote:
>the real question here is "why do you think you need an abstract class
>in common lisp, and what do you think it would get you?"
It's interesting to note that Flavors, one of the two main influences on
the design of CLOS, *did* have the notion of abstract classes. DEFFLAVOR
had an :ABSTRACT-FLAVOR option that indicated that the flavor couldn't be
instantiated by itself. It also had :REQUIRED-INSTANCE-VARIABLES and
:REQUIRED-METHODS, to declare that a flavor incorporating this flavor as a
base has to define these instance variables (what CLOS calls slots) and
methods, since methods in the base flavor will reference them
(:REQUIRED-METHODS is analogous to C++'s technique where the base class
declares a method with '= 0'). These things allow the base class to define
a protocol that mixins are supposed to implement.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <··············@alum.mit.edu>,
> David Bakhash <·····@alum.mit.edu> wrote:
> >the real question here is "why do you think you need an abstract class
> >in common lisp, and what do you think it would get you?"
>
> It's interesting to note that Flavors, one of the two main influences on
> the design of CLOS, *did* have the notion of abstract classes. DEFFLAVOR
> had an :ABSTRACT-FLAVOR option that indicated that the flavor couldn't be
> instantiated by itself. It also had :REQUIRED-INSTANCE-VARIABLES and
> :REQUIRED-METHODS, to declare that a flavor incorporating this flavor as a
> base has to define these instance variables (what CLOS calls slots) and
> methods, since methods in the base flavor will reference them
> (:REQUIRED-METHODS is analogous to C++'s technique where the base class
> declares a method with '= 0'). These things allow the base class to define
> a protocol that mixins are supposed to implement.
(defclass an-abstract-class ()
()
(:abstract-p t))
(defclass I-cannot-be-subclassed ()
()
(:sealed t))
any taker?
Cheers
--
Marco Antoniotti ===========================================
David Bakhash <·····@alum.mit.edu> writes:
> If you get caught trying to find rigorous analogies between CLOS and
> (say) Java's object system, then you'll be troubled because in Java
> (and C++), methods belong (and I think are lexically defined) inside
> the classes to which they apply. Since methods belong to a paticular
> class, they can't dispatch based on multiple classes (at least not
> without ugly CASE-like statments or something).
Yes, in Java the methods are textually inside the class definitions.
Nonetheless, the existing Java syntax would work just fine for
multi-arg dispatch.
(Indeed, if you know about the multi-arg dispatch, you'll find that
some of the descriptions of how method lookup works in Java could
remain unchanged. Because the authors never read what they wrote from
the point of view of someone who might think all args were treated
dynamically, they failed to see that their words did not make it clear
that dynamic lookup *wasn't* what happened.)
> ... it's best to drop what you know and try learning CLOS with
> an open mind. ...
I agree with you there.
-- jeff