Re: Any examples of modules using GOOPS?

[Marius Vollmer <mvo@zagadka.ping.de>]

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

> It is of course good to discuss these things as early as possible.

Yes.  I now had a superficial look at the code and I'm *really*
impressed.  Will it be folded into the Guile core distribution?

> The syntax is
> 
>   (define-class NAME (SUPER ...) SLOT ... CLASS-OPTION ...)
> 
> Since
> 
>   SLOT ::= SYMBOL | (SYMBOL SLOT-OPTION ...)
>   CLASS-OPTION ::= KEYWORD VALUE
> 
> it is unambiguous where the options start.  (One could even allow
> intermixed slot definitions and options.)

Yes, this is nice.  But I think that removing the parenthesis could
also be seen as a gratitous incompatability with existing code.  That
Goops isn't 100% percent compatible with STk (or other systems) isn't
really an argument, I think.  It should be as compatible as
reasonable, so that simple things are portable.  Having a incompatible
define-class syntax means that *no* code is portable, for purely
aesthetic reasons.  I don't think people will react to that too well.

But then again, how compatible are the existing Scheme object systems
anyway?

> > Why is that?  Can't you just construct a init-thunk from the
> > init-form?
> 
> Yes, you're right that this is possible.  However, this means that the
> define-class macro needs to scan through all slot options, looking for
> #:initform.  In the original STKlos implementation this was avoided by
> postponing the creation of the closure until the getters-and-setters
> computation inside the MOP.

I still haven't read that part of the code, so I don't know why this
is postponed.  The define-class macro can be MOPified as well, I
think, if we want to make the processing of slot options customizable.
define-class could find the meta-class and call a generic function
canonicalize-slot-option-using-metaclass or something like that.

[ I'm thinking here about the issue that certain slot options receive
  special treatment by define-class (the function
  canicalize-direct-slot in the AMOP-MOP, which is *not* a generic
  function).  A user of the MOP might want to have his own special
  syntactic processing of his own slot-options for the expansion of
  the define-class form. ]

> In the few cases where you want to evaluate a closure for every
> instance initialization, it's no big trouble to write the lambda
> expression.

Agreed.
 
> Also, I would like to have a simple rule for evaluation of
> slot-option arguments.  Currently it is: All slot-option arguments
> are evaluated at class-definition, except for getter, setter, and
> accessor names.  I think it's nice not to have to add #:init-form to
> those exceptions.

Hmm, I don't consider this a strong argument.  As you said, it's a
about taste and style, and I think good taste is not to introduce
gratitious incompatibilities with existing systems.  I don't know how
fragmented the existing systems already are, tho.

In any case, Goops is damn exciting stuff!  Thanks for doing this!