Re: Ensuring a method exists
- From: Pascal Costanza <pc@xxxxxxxxx>
- Date: Thu, 28 Sep 2006 14:53:41 +0200
Javier wrote:
Pascal Costanza ha escrito:
In Java, interfaces are only necessary to make the static type system
happy. When different classes offer similar functionality and you want
to use their instances in the same place, they have to have the same
type. So either, they are derived from the same common superclass, one
is derived from the other, or they implement the same interface.
Interface types are more flexible than class types because the former
are not restricted to single inheritance. If Java classes would support
multiple inheritance, interfaces would not be necessary, but abstract
classes would be sufficient (like in C++).
Since Common Lisp is dynamically typed, you don't have to worry about
all these things. When different classes offer functionality and you
want to use their instances in the same place, you ... just use them.
Thanks Pascal. Let see if I understand it, I'll give up you an example:
For example you develop a sound application, like Cubase. Cubase uses
VST, which is an especification of abstract classes in C++. Basically,
the devolper enforces you to write a series of methods to ensure that
your plugin will work correctly in the entire system. A similar issue
happens with Java Sound.
What I don't understand from your answer is that interfaces (and
abstract classes) are something that only strongly typed languages
need. I understand that an interface is a void framework of methods
primaly, independetly of the data type of their methods or fields. How
would a CLOS programmer would enforce other users to develop plugins
for their application without an abstract class or interface? (just
asking).
The equivalent of defining interfaces, making them public and asking client software to implement them is to define generic functions, making them public and asking client software to implement them. So, for example, you can define a generic function like this:
(defgeneric add (collection object))
(defgeneric rem (collection object))
You can even define default behavior alongside:
(defgeneric add (collection object)
(:method ((collection list) object)
(cons object collection)))
(defgeneric rem (collection object)
(:method ((collection list) object)
(remove object collection)))
There are some examples in the HyperSpec and in the CLOS MOP specification. For example, print-object, initialize-instance, slot-unbound, slot-missing, and so on, are generic functions that are primarily there for users to define methods on, not for calling them.
What you don't have in CLOS is that you can force client software to explicitly implement methods. It's left up to the responsibility of the programmer to define the right methods, or to leave them out when they are actually not necessary.
It's important to note that static typing doesn't really help you a lot, either. One of the pro-static-typing arguments is that it require programmers to at least think about their design and provide empty methods in case they are not really needed, making that design decision an explicit one. But for example in Java, such a method can still throw an OperationNotSupportedException, divide by zero, or do other silly things. "Modern" development environments like Eclipse even fill in such methods automatically for you - go figure.
So to summarize, a CLOS programmer mainly uses documentation to advertise what a client program has to do to fulfill the needs of a framework.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
.
- Follow-Ups:
- Re: Ensuring a method exists
- From: Javier
- Re: Ensuring a method exists
- References:
- [CLOS] Ensuring a method exists
- From: Didier Verna
- Re: [CLOS] Ensuring a method exists
- From: Lars Rune Nøstdal
- Re: [CLOS] Ensuring a method exists
- From: Didier Verna
- Re: [CLOS] Ensuring a method exists
- From: Ken Tilton
- Re: [CLOS] Ensuring a method exists
- From: Christophe Rhodes
- Re: [CLOS] Ensuring a method exists
- From: Ken Tilton
- Re: [CLOS] Ensuring a method exists
- From: Pascal Costanza
- Re: [CLOS] Ensuring a method exists
- From: Ken Tilton
- Re: [CLOS] Ensuring a method exists
- From: Pascal Costanza
- Re: Ensuring a method exists
- From: Javier
- Re: Ensuring a method exists
- From: Pascal Costanza
- Re: Ensuring a method exists
- From: Javier
- [CLOS] Ensuring a method exists
- Prev by Date: Re: Aha! moments
- Next by Date: Re: All paths through a tree
- Previous by thread: Re: Ensuring a method exists
- Next by thread: Re: Ensuring a method exists
- Index(es):
Relevant Pages
|
|