From: Erik Naggum
Subject: Re: How make an abstract class in CLOS?
Date:
Message-ID: <3168070395260015@naggum.no>
* "Sergio" <········@teleline.es>
| How can i make an abstract class using defclass?
What's an abstract class?
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.no> writes:
>
> * "Sergio" <········@teleline.es>
> | How can i make an abstract class using defclass?
>
> What's an abstract class?
A class you won't instantiate but which you can (and usually will)
make subclasses of.
But to answer Sergio's question: You simply "defclass" it
like any other class, that's all there is to it ;)
--
(Rmz)
Bj\o rn Remseth !Institutt for Informatikk !Net: ···@ifi.uio.no
Phone:+47 91341332!Universitetet i Oslo, Norway !ICBM: N595625E104337
From: Friedrich Dominicus
Subject: Re: How make an abstract class in CLOS?
Date:
Message-ID: <87zophe81a.fsf@frown.inka.de>
Erik Naggum <····@naggum.no> writes:
> * "Sergio" <········@teleline.es>
> | How can i make an abstract class using defclass?
>
> What's an abstract class?
It's an class which one can see as a skeleton, but which can not be
instantiated, so descendants are expected to implement the abstract
features. I guess such a thing does not make sense in Common Lisp
but it plays a role e.g in Eiffel, Sather, C++ as a design tool.
Regards
Friedrich
From: Erik Naggum
Subject: Re: How make an abstract class in CLOS?
Date:
Message-ID: <3168084176101935@naggum.no>
* Friedrich Dominicus <···················@inka.de>
| It's an class which one can see as a skeleton, but which can not be
| instantiated, so descendants are expected to implement the abstract
| features. I guess such a thing does not make sense in Common Lisp
| but it plays a role e.g in Eiffel, Sather, C++ as a design tool.
Let's see is the person requesting this can describe it well enough
to be implementable or even desirable in Common Lisp. I'm not too
interested in what it would mean in another language, but this is
probably because I occasionally use English expressions in Norwegian
and vice versa and thus know just how incredibly embarrassing it can
be to forget which language one is using.
#:Erik
--
If this is not what you expected, please alter your expectations.
From: Andrew Cooke
Subject: Re: How make an abstract class in CLOS?
Date:
Message-ID: <8geohu$49$1@nnrp1.deja.com>
The machine I have the ANSI spec on isn't running at the moment, so I
may have the wrong names here, but perhaps you could consider using
defgeneric as the equivalent in some way of an abstract class, and
defmethod as implementing that class? (I'm not sure it's particularly
useful to do so, however.)
Andrew
http://www.andrewcooke.free-online.co.uk/index.html
In article <··············@frown.inka.de>,
Friedrich Dominicus <···················@inka.de> wrote:
> Erik Naggum <····@naggum.no> writes:
>
> > * "Sergio" <········@teleline.es>
> > | How can i make an abstract class using defclass?
> >
> > What's an abstract class?
>
> It's an class which one can see as a skeleton, but which can not be
> instantiated, so descendants are expected to implement the abstract
> features. I guess such a thing does not make sense in Common Lisp
> but it plays a role e.g in Eiffel, Sather, C++ as a design tool.
>
> Regards
> Friedrich
>
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Erik Naggum
Subject: Re: How make an abstract class in CLOS?
Date:
Message-ID: <3168106950435552@naggum.no>
* Andrew Cooke
| The machine I have the ANSI spec on isn't running at the moment, so
| I may have the wrong names here, but perhaps you could consider
| using defgeneric as the equivalent in some way of an abstract class,
| and defmethod as implementing that class? (I'm not sure it's
| particularly useful to do so, however.)
On the contrary, this is really what we're looking for. In my view,
this is the only intelligent transposition of the "abstract class"
bullshit from the C++ world into areal object-oriented system, and
it shows that a fairly simple concept (generic functions) needs to
be reimplemented in a round-about, counter-intuitive way in an "OO"
system that fails to understand that classes do not "own" methods.
"Abstract classes" do not have anything to do with the _classes_.
It's a misfeature of the encapsulation mechanism in C++ classes,
which is itself a misfeature of its implementation specifics and
its legacy from C and a misunderstanding of Simula's mechanisms.
It was said back in the early 1990's data communication that the
question "What is X.25?" could be asked by only ignorants and deeply
sarcastic experts. Later, "What is a database?" and "What is
object-orientation?" have become similar questions. I thought it
was appropriate to ask "What is an abstrat class?" the same way.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.no> wrote:
> On the contrary, this is really what we're looking for. In my view,
> this is the only intelligent transposition of the "abstract class"
> bullshit from the C++ world into areal object-oriented system, and
> it shows that a fairly simple concept (generic functions) needs to
> be reimplemented in a round-about, counter-intuitive way in an "OO"
> system that fails to understand that classes do not "own" methods.
>
> "Abstract classes" do not have anything to do with the _classes_.
> It's a misfeature of the encapsulation mechanism in C++ classes,
> which is itself a misfeature of its implementation specifics and
> its legacy from C and a misunderstanding of Simula's mechanisms.
Close, but not quite. An "abstract class" is closer to a protocol,
i.e. a set of cooperating methods, than it is to a single method.
This means that you'd need to define either a set of generic functions
or my-abstract-class-protocol generic function that returns a defined
set of functions.
Dan Pierson, Control Technology Corporation
···@control.com
From: Erik Naggum
Subject: Re: How make an abstract class in CLOS?
Date:
Message-ID: <3168170036820281@naggum.no>
* Dan L. Pierson <···@control.com>
| Close, but not quite. An "abstract class" is closer to a protocol,
| i.e. a set of cooperating methods, than it is to a single method.
Huh? Obviously, you need more than one generic function if the
abstract class defines more than one function that has to be
implemented by the real classes. I'm not sure what you're arguing
against, or possibly why you think this is non-obvious.
#:Erik
--
If this is not what you expected, please alter your expectations.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Dan L. Pierson <···@control.com>
>| Close, but not quite. An "abstract class" is closer to a protocol,
>| i.e. a set of cooperating methods, than it is to a single method.
>
> Huh? Obviously, you need more than one generic function if the
> abstract class defines more than one function that has to be
> implemented by the real classes. I'm not sure what you're arguing
> against, or possibly why you think this is non-obvious.
I'm not sure what you're arguing against, either.
Basically, in languages that have them, abstract classes are a way of
encoding some rules about the protocol that the class hierarchy is intended
to implement within the class definitions. In C++, you create an abstract
class by defining a "pure virtual function" in the class, which is like
Flavors's :REQUIRED-METHOD declaration; this indicates that classes in that
hierarchy are required to implement that method, because some methods in
the superclass will do the equivalent of (<method> self ...) or
this-><method>(...). I think Java's "interface" classes are similar.
Most OO languages don't provide any way to define protocols in any rigorous
fashion. I think Xerox PARC's research into Aspect-Oriented Programming
tries to include this, but as far as established OO languages go, abstract
classes and interface classes are about the only thing there is.
--
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:
> Basically, in languages that have them, abstract classes are a way
> of encoding some rules about the protocol that the class hierarchy
> is intended to implement within the class definitions. In C++, you
> create an abstract class by defining a "pure virtual function" in
> the class, which is like Flavors's :REQUIRED-METHOD declaration;
> this indicates that classes in that hierarchy are required to
> implement that method, because some methods in the superclass will
> do the equivalent of (<method> self ...) or this-><method>(...). I
> think Java's "interface" classes are similar.
How does this work in Flavors? I am very unfamiliar with Flavors.
Are method definitions lexically connected with class definitions? If
not, how would the system know when to say, "Hey buddy, you forgot
this required method!"
In CLOS this doesn't make much sense unless you wanna add a method
which uses the MOP to scan a set of generic functions to make sure
they have a method specialized on a given class. But when do you
wanna run that code? At the end of your system load or something? I
suppose that would be of some use.
--
Craig Brozefsky <·····@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
In article <··············@piracy.red-bean.com>,
Craig Brozefsky <·····@red-bean.com> wrote:
>Barry Margolin <······@genuity.net> writes:
>
>> Basically, in languages that have them, abstract classes are a way
>> of encoding some rules about the protocol that the class hierarchy
>> is intended to implement within the class definitions. In C++, you
>> create an abstract class by defining a "pure virtual function" in
>> the class, which is like Flavors's :REQUIRED-METHOD declaration;
>> this indicates that classes in that hierarchy are required to
>> implement that method, because some methods in the superclass will
>> do the equivalent of (<method> self ...) or this-><method>(...). I
>> think Java's "interface" classes are similar.
>
>How does this work in Flavors? I am very unfamiliar with Flavors.
>Are method definitions lexically connected with class definitions? If
>not, how would the system know when to say, "Hey buddy, you forgot
>this required method!"
Although Flavors associates methods with specific flavors, like most other
OO languages, it's like CLOS in that methods are not lexically part of the
flavor definition. The Chinual says "This keyword allows the error of
having no handler for the message to be detected when the flavor is defined
(which usually means at compile time) rather than at run time."
>In CLOS this doesn't make much sense unless you wanna add a method
>which uses the MOP to scan a set of generic functions to make sure
>they have a method specialized on a given class. But when do you
>wanna run that code? At the end of your system load or something? I
>suppose that would be of some use.
Flavors has a macro (compile-flavor-methods &rest flavor-names) that can be
put in a file to be compiled. When this form is compiled, all the combined
methods are genated and put into the resulting object file. I think this
will perform the :REQUIRED-METHOD consistency checking. If you don't use
this, then the consistency checking will indeed be deferred to run-time,
the first time an instance of a sub-flavor is instantiated.
I think most CLOS implementations have something that's analogous to this,
to precompile its data structures.
--
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.
From: Hartmann Schaffer
Subject: Re: How make an abstract class in CLOS?
Date:
Message-ID: <392dfd41@news.sentex.net>
In article <··············@piracy.red-bean.com>,
Craig Brozefsky <·····@red-bean.com> writes:
> ...
> In CLOS this doesn't make much sense unless you wanna add a method
> which uses the MOP to scan a set of generic functions to make sure
> they have a method specialized on a given class. But when do you
CLOS'es object model doesn't exactly tie methods to one class.
> wanna run that code? At the end of your system load or something? I
> suppose that would be of some use.
>
--
Hartmann Schaffer
Friedrich Dominicus <···················@inka.de> writes:
> It's an class which one can see as a skeleton, but which can not be
> instantiated, so descendants are expected to implement the abstract
> features. I guess such a thing does not make sense in Common Lisp
> but it plays a role e.g in Eiffel, Sather, C++ as a design tool.
You don't want to do this (why do I always get the feeling that
the hardcore OO camp is living in a different dimension than I?),
but here are a few statements that indicate that you can put
such handcuffs on you if you use the mop:
USER(19): (defclass abstract (standard-class)
())
#<STANDARD-CLASS ABSTRACT>
USER(20): (defclass dummy ()
()
(:metaclass abstract))
#<ABSTRACT DUMMY>
USER(21): (defmethod make-instance ((x abstract) &rest initargs)
(error "You're not allowed to make me!"))
#<STANDARD-METHOD MAKE-INSTANCE (ABSTRACT)>
USER(22): (defclass foo (dummy)
())
#<STANDARD-CLASS FOO>
USER(23): (defmethod gobble ((x dummy))
(format t "Gobble-gobble!~%"))
#<STANDARD-METHOD GOBBLE (DUMMY)>
USER(24): (make-instance 'dummy)
Error: You're not allowed to make me!
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart)
1: Abort #<PROCESS Initial Lisp Listener>
[1] USER(25): :pop
USER(26): (make-instance 'foo)
#<FOO @ #x46ce682>
USER(27): (gobble *)
Gobble-gobble!
NIL
USER(28):
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> You don't want to do this (why do I always get the feeling that
> the hardcore OO camp is living in a different dimension than I?),
> but here are a few statements that indicate that you can put
> such handcuffs on you if you use the mop:
whoops, seems like Tim Bradshaw had already made an almost identical
posting that I missed at first sight - sorry about that...
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
>
> > You don't want to do this (why do I always get the feeling that
> > the hardcore OO camp is living in a different dimension than I?),
> > but here are a few statements that indicate that you can put
> > such handcuffs on you if you use the mop:
>
> whoops, seems like Tim Bradshaw had already made an almost identical
> posting that I missed at first sight - sorry about that...
Do you think this is enough? :{ Just wait for the objection "but
this is a runtime and not a compile-time error!" :{
Cheers
--
Marco Antoniotti ===========================================