Re: Semantics of :initform and oset-default

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> It was pointed out that the initform is supposed to be evaluated so there
> is a bit of a hybrid behavior which allows:

Ah, the historical account is quite helpful: now the weird hack makes
a lot more sense.

> A slot with :allocation :instance (the default) would have the form
> evaluated when it is constructed.  A slot with :allocation :class is
> evaluated when the class is created.  If just the symbol is in there, it
> acts as a constant value (ie - no function form to call)

Yes, this is the standard CLOS behavior, indeed.

ELISP> (setq moose 1)
> 1
ELISP> (oset-default 'foo test '(symbol-value 'moose))
> (symbol-value 'moose)
ELISP> (foo "hi")
> [object foo "hi" 1]

Yuck!  You just forced EIEIO to use runtime code generation (since it
had to turn the (symbol-value 'moose) list into a chunk of code).

> I don't know if that is correct or not.  It didn't occur to me that you
> could do that until I tried explaining just now.

Hmm... I wonder if someone relies on this misfeature.

> Here is the documentation I had used at the time:
> http://www.lispworks.com/documentation/HyperSpec/Body/m_defcla.htm

Yes, this describes the :initform semantics, but not its interaction
with `oset-default' since CLOS doesn't have anything like
`oset-default'.

> It goes on to talk about the lexical environment which I didn't/don't know
> how to deal with.

It's easy: turn every initform in the defclass definition into a lambda
expression and store that (i.e. a closure instead of a "form") into the
class's slot descriptor.  Then, instead of `eval', use `funcall' in
(the equivalent of) eieio-default-eval-maybe.


        Stefan "Every time you have to use `eval', a baby cries"