Re: Some questions about GOOPS and CLOS in general

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:

> Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:


> It is possible to talk very long about the advantages/disadvantages of
> each approach.  I won't do that here.  I just note that Dylan chose
> the second approach.

Are there any papers that discuss the advantages and disadvantages of
these two approaches?   As I understand the CLOS paradigm, the state of an object O
belonging to class C can be manipulated by a function that doesn't necessarily 
belong to C.  Such a function operating on the state of a foreign class' object
breaks the class boundary and creates a side effect.

This may not be a big problem since each class belongs to a certain
module and the accessor (get/set*) functions are created within this
module so that the module can and will protect the class' objects and 
exports the accessor functions.  Right? 

A module can't protect a class if there is more than one class located
in the module.  That means that there is exactly one class per module.
I think here is a redundancy.  A module imports definitions
from other modules and a class imports (extends) other classes.  
When you want to write a class that extends the class X located in module MX
you must write down the same information twice: 1) use module MX, 2) 
derive from class X.

Java and the system designed by Matthias Blume doesn't use modules
at all.  Instead it is possible to design a *module as a special kind of class*:
A module is a class with exactly one instance.


My idea is:

;; module located in file "mod1"        ;; class located in file "filled-cycle"
(module (ice-9 mod1)			(class (oop filled-cycle)
  (open (ice-9 debug) ...)		   (open (oop cycle))
  (export (a b c ...))			   (export color ...))

(define a 12)				(define color 0); default color
...                                     ...

;; use the module			;; use the class
(define m1				(define fc1 
   (module-access (ice-9 mod1)))          (module-access (oop filled-cycle)))
(define m2                              (define fc2 
   (module-access (ice-9 mod1)))          (module-access (oop filled-cycle)))
(m1 a 1)                                (fc1 color 1)
(m2 a 2)                                (fc2 color 2)

(m1 a) -> 2                             (fc1 color) -> 1
(m2 a) -> 2                             (fc2 color) -> 2

(eq? m1 m2) -> #t                       (fc1 radius) -> 0 ;; inherited
                                        (fc1 radius 10)
                                        ...


It would be nice if we could design a low level OO interface and
plant GOOPS and possibly other OO interfaces on top of it.

Just like the new module implementation sits on top of environments
and thus it is possible to use any module configuration language you want,
I think it should be possible to design a low level (C-based) OO interface
that guile's OO implementations can use.


> struct has a type (CAR), which itself is a struct.  The type of this
> stuct is a vtable, i.e. a struct which has itself as type.  The
> relations of the layouts follow from this.

Okay.  But why is the layout stored in the car?  Isn't is sufficient to
just store the pointer to the layout in the cdr?  


> > * The class' slots seems to be implemented as a list.  Isn't it possible to
> >   store them directly into the class?
> 
> Strictly, they don't belong there since the class object is only a
> description of a type of instances.  

Yes of course.  I meant to say "in the object".  Sorry.


Jost