[Xotcl] Issue with mixin delete

[Scott Gargash]

Gustaf Neumann <neumann at wu-wien.ac.at> wrote on 05/09/2006 03:54:49 AM:

> Scott Gargash schrieb:
> >
> > I.e., you can't forward the "mixin delete" to an object of another
> > class.  If the mixin to be deleted is present in the call stack, it
> > appears that the mixin can't be deleted. Not that I expected it to
> > work, but it seems worth noting.
> >
> if you have a case that goes beyond "do not remove actvive mixins from
> the before part of active mixin classes"), please send an example.

No, the same conditions apply. It's just that the BEFORE part includes anything invoked indirectly
by the BEFORE part.  Sometimes you don't have knowledge of what some other object will do when
invoked, and it can be a subtle bug.

> We have to deal with the following cases when we have e.g. a precedence
> order  M1 M2 M3 M4, and the following happens in the BEFORE part of M2:
>
> a   chain is set to: M1 M3 M4    (your case, you want to continue with M3)
> b   chain is set to: M1 M4           defensible M4
> c   chain is set to: M2 M1 M3 M4    under current semantics, continue with M1
> d   chain is set to: M4 M2 M3 M1    continue with M3, M4 will never by
> invoked

Yup, that's exactly the behavior I (naively) had expected.

But to be clear, what is the current behavior of 'next' for each of these cases? To unwind the call
stack?  When can the updated mixin list be considered to have taken effect?

> The general problem is pretty similar to the "immediate" and "logical"
> update view in logic languages,

Good analogy, that makes sense.

> but it goes back to Lindholm and Richard
> O'Keefe (ROK) from 87, */Efficient implementation of a defensible semantics
> for dynamic Prolog code/* (unfortunately, could not find this fine paper on
> the net).

There's also a brief discussion of this in O'Keefe's book "The Craft of Prolog".

> The most promissing approach not mentioned yet is to develop a
> c-level implementation of mixin/instmixin/filter/instfilter delete,
> which simply flags the entry in the chain as deleted.....

Interestingly, that's how I assumed it was implemented, which is probably why I was surprised.

      Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://alice.wu-wien.ac.at/pipermail/xotcl/attachments/20060509/5592a143/attachment.html