Re: Any examples of modules using GOOPS?

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

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

> (I promise to answer questions about it when it has been released, but
> I can't promise that now.)

Hi, 

I like to take a few issues with your argumentation below.  If you
don't feel like discussing this, that's fine.  I haven't even looked
at the code yet.
 
> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > The problem in this case is that goops appears to want the slots as
> > individual lists after the super definition...
> 
> Yes, since that extra air of parenthesis seemed superfluous I removed
> them.

Are you talking about:

    (defclass NAME (BASE ...)
      (SLOT ...))

versus

    (defclass NAME (BASE ...)
      SLOT ...)

?  If that is the case, I think the parens should be kept, because the
real definition is:

    (defclass NAME (BASE ...)
      (SLOT ...)
      OPTION ...)

Even if there are no options now, there will be in the future,
especially when we have a MOP.

> #:initform is not Schemey.

I think it is.

> #:initform is passed an expression which will be evaluated in the
> environment of the class every time an instance is initialized.
> This requires the implementation to 1. store a pointer to the class
> environment, and 2. use `local-eval'.

Why is that?  Can't you just construct a init-thunk from the
init-form?  CLOS has a :initform which works exactly like this.  The
MOP extends this with :initfunction, and a :initform is implemented by
constructing a lambda expression at defclass expansion time.  Like

    (foo :initform (+ bar 1))
    =>
    (make-slot 'foo :initform '(+ bar 1) :initfunction (lambda () (+ bar 1)))

The :initform is only retained for display purposes.  The lexical
environment of the :initfunction is that of the defclass macro.

This means that the values of other slots are not available to the
:initfunction, but I'm not sure if that would lead to well defined
semantics.  If you want initial values to be computed from one
another, I think one should extend the generic function
initialize-instance (or shared-initialize) for that class.

> This can cause trouble for compilers and places restrictions on
> future interpreters (need to implement `local-eval').

I think the CLOS behaviour is entirely implementable with standard
lexical closures.  Very Schemey, in fact.  :init-form could be an
abbreviation for your :init-thunk, where you give just the body.

- Marius