Re: EIEIO built in methods -- question

[Pascal J. Bourguignon]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> David Engster <deng@randomsample.de> writes:
>
>> Eric Abrahamsen writes:
>>> There's the eieio-singleton class provided as part of the package, which
>>> does the same thing in principle: only lets you create one instance of
>>> the class.
>>
>> [...]
>>
>>> This is the same idea, yes? 
>>
>> Yes. You can simply put eieio-singleton in your list of superclasses and
>> you will inherit this behavior.
>>
>>> I don't know why "name" and "slots" aren't passed to
>>> `call-next-method'.
>>
>> That's done by default. You only provide arguments to `call-next-method'
>> if you'd like to override them.
>
> Thanks! That's helps quite a bit.

Notice that in CLOS, you are forbidden to provide new arguments that
would change the chain of methods that will be called:

   "When providing arguments to call-next-method, the following rule
    must be satisfied or an error of type error should be signaled: the
    ordered set of applicable methods for a changed set of arguments for
    call-next-method must be the same as the ordered set of applicable
    methods for the original arguments to the generic
    function. Optimizations of the error checking are possible, but they
    must not change the semantics of call-next-method."

Since CLOS can dispatch on all the mandatory parameters, it's a strong
constraint.

Now, in the case of eieio, it can only dispatch on the first argument,
so as long as you keep it, or an instance of the same class, you should
be able to do as you wish.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.
You can take the lisper out of the lisp job, but you can't take the lisp out
of the lisper (; -- antifuchs