No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Issue with mixin delete
From: Scott Gargash <scottg_at_atc.creative.com>
Date: Tue, 9 May 2006 10:09:20 -0600
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
Date: Tue, 9 May 2006 10:09:20 -0600
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