Re: EIEIO built in methods -- question

[David Engster]

Eric Abrahamsen writes:
> Oh dear, something is very confused here! My understanding of the
> CLOS/EIEIO model of generic methods and inheritance is that you're
> basically just creating a glorified hook that gets called as one of a
> chain of hooks, and that you continue the chain with call-next-method.
> It's call-next-method that calls a method that produces a return value,
> not my actual implementation of initialize-instance.

`initialize-instance's return value is not used. It's just there to
initialize the instance, which in EIEIO it delegates to
`shared-initialize'.

> ELISP> (setq g (make-instance 'persisty "good" :file "/home/eric/good.txt"))
> [object persisty "good" "/home/eric/good.txt"] <--- produces success message
>
> ELISP> (setq b (make-instance 'persisty "bad" :file "/home/eric/bad.txt"))
> *** Eval error ***  You can't use that file
> ELISP> b
> *** Eval error ***  Symbol's value as variable is void: b
>
> Unless there's some potential fatal flaw with this that I'm not seeing,
> this is precisely the behavior I wanted.

You can of course throw an error. However, this simply shifts all the
hard work to the *user* of your class. It's him now who has to make sure
that he is not creating a `persisty' for a file for which this was done
already, or otherwise his application will throw an error. How he does
that is up to him, but he has to do it every time he constructs an
instance.

Wouldn't it be much nicer if the class constructor would simply return
the *already existing* instance instead? This is the main problem.

You can achieve that through different methods, depending on what your
language offers. The easiest way, which I guess should work in any
OO-language, is to use a factory method or function. This is also what
Pascal suggested with his `make-persistent-thingy'. However, this has
several drawbacks in practice: you have to document it, and ideally you
should forbid other ways to create objects of your type, which isn't
always possible.

The `constructor' however actually returns the instance of your
`persisty', so he can return an already existing object. This is what my
code did. You should replace the `oref' there with `oref-default',
though.

> I'll do some more experimentation with class-allocated slots, that's
> still a bit opaque to me.

This is explained very nicely in Seibel's book.

> I don't think I'm necessarily stuck in Python/C++ etc, but I do think
> it's helpful to tell people "what it looks like over here".

IMO CLOS really begins to show its powers when you start to use multiple
dispatch. Unfortunately, EIEIO does not support that...

-David