No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Issue with mixin delete
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 09 May 2006 19:15:22 +0200
Scott Gargash schrieb:
>
> > 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 current implementation the mixin command is an immediate update (it
replaces the old mixin chain), "next" searches for the current class
(M2), but does not find it, and assumes that it is at the end of the
mixin chain.
>
> > 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.
>
i will check this option out in more detail (earliest this weekend). so,
don't hold your breath...
-gustaf
Date: Tue, 09 May 2006 19:15:22 +0200
Scott Gargash schrieb:
>
> > 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 current implementation the mixin command is an immediate update (it
replaces the old mixin chain), "next" searches for the current class
(M2), but does not find it, and assumes that it is at the end of the
mixin chain.
>
> > 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.
>
i will check this option out in more detail (earliest this weekend). so,
don't hold your breath...
-gustaf