Re: Any examples of modules using GOOPS?

[Mikael Djurfeldt <mdj@nada.kth.se>]

Jee, guys... you're really [we have an expression in Swedish which
literally translates to "hot on the porridge".  What is that in
English?].

How did you discover this code?

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

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.  That this makes Goops incompatible with STKlos is not an
argument, since it will be incompatible for other reasons anyway.
(In this respect, it is just an advantage that Goops and STKlos code
differs also superficially.)

But there will be an STKlos compatibility module added which will be
able to run STKlos code.

In my view this change makes the code prettier.  (This was one of the
few things which I thought was ugly when I first encountered STKlos.
The other thing I found ugly was the generalized set, but that has
been resolved now. :)

> next bit that'll bite you after you change that, you need to use
> guile's #: style keywords;

Note that it of course also is possible to do

  (read-set! keywords 'prefix)

and use : style keywords.

> (also, initform is changed to init for some reason).

The reason is this:

#:initform is not Schemey.  #: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'.  This can
cause trouble for compilers and places restrictions on future
interpreters (need to implement `local-eval').

#:initform has been replaced by #:init and #:init-thunk.

#:init       takes a value
#:init-thunk takes a thunk which is evaluated every time an instance
             is initialized

/mdj