This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Some questions about GOOPS and CLOS in general
Hi,
just a quick comment:
> C++: A * B
> TOM: [A multiply B]
> CLOS: (multiply A B)
>
> So... huh?!
Also hu? :)
C++ A.moveTo(...)
A.multiply(B)
etc.
> In any OO paradigm I've worked with, methods return values without
> problems.
Yes. These classes are "factory" classes. They simply return
a new object.
> > In the OO paradigm you don't associate methods with classes. They
> > *belong* to exactly one class' object and they will go away when the
> > object goes away.
> In some particular OO paradigms. Obviously, not in CLOS and not in
> GOOPS. So this argument is obviously not general enough to be of any
> value to this discussion.
Then CLOS and GOOPS are broken. :) In CLOS how can you protect a slot
from beeing changed by a foreign method? You cannot since in CLOS
methods do not belong to an object. This means that they can operate
on the whole set of objects that populate your system causing unwanted
side effects.
> The problem is that this introduces redundancy. The function "knows"
> which other functions it calls. But the module doesn't know
> that. Therefore you have to type the same information twice: function
> f calls function g, and therefore you have to tell the current module
> F to import a function from module G.
True. But it wasn't me who decided to use scheme as the base
for the GNU extension language. :)
> On another line, one of the basic assumptions of CLOS is that
> encapsulation is orthogonal to OO - in other words, Java
> implementation of modules as singletons is Java's design choice rather
> than obvious thing to do in any OO system.
Java and other good OO implementations don't have modules at all.
In Java and Eiffel a module /is a/ class. And a package is just
a set of modules (module == class).
> For example, it's a really good idea to program all the matrix classes
> in one module - direct access to slots,
I think when you say "module" you really mean the package concept.
If I understood Mikael correctly there is exactly one class per module.
> code - allows you to omit *lots* of annoying method calls, while still
> keeping clean exported interface (this is in a way similar to GC,
> where low-level stack manipulation is hidden between 'you never type
> delete' interface).
When you want to put more than one class into a module, how do you
export accessor X for class a and accessor X for class b?
> Precisely - so why do you insist on encapsulating classes?
class piano has slot pedal
class bike has slot pedal
class s inherits from piano and bike.
You must not merge these two slots.
> > But he treats modules just like classes and I quite like the trick.
> > Normaly a module /owns/ one or more classes. In his system a module
> > /is a/ class.
>
> Class in GOOPS is a type.
Yes, but why do you say that?
> My suggestion would be not to try to integrate it at all - the two are
> separate entities by design, as one handles datatypes and the other
> encapsulation.
The problem with goops is that an object doesn't protect its slots.
So the module has to handle this.
> Even if fc1 is a lambda, this is misleading. It is also vastly
> inferior to any OO with multiple dispatch (see below).
May be. But multiple dispatch has the problem that the methods
do neither belong nor are they associated with the object they
manipulate.
> To repeat: while this is true, this method can't give you polymorphism
> of the sort (m1 format binary-formatter) vs (m1 format text-formatter)
I don't understand. Depending on the type of m1 format is either
binary-formatter or text-formatter.
> > A method with no arguments returns the slot (is a getter) or a setter
> > with an implicit argument, for example (fc1 'set-color-to-1). A method
> > with 3 or more arguments is a always setter.
>
> How about (get-nth list 5) ?
I assume get-nth is an object of the class <get-nth> and list
is the method selector. If the slot "list" of the class' object "get-nth"
is a variable, it will get the value 5. If it is a getter it will
return a computed value, if it is a setter, it will do something with
the value 5.
> (generic-set! (get-nth list 5) 15)
What does that do? As I understand scheme you cannot set! a list
to something.
Jost