On Fri, 2002-07-12 at 00:34, Daniel Stodden wrote: > why? removal. consider removing an invocation chain from another. now > the fun part is that not the first occurence of the list to remove is > removed but the _last_ occurence. > > might have originated at MS from a side effect. but it's documented in > the class docs nonetheless. > removals are therefore implemented in mono by reverting the internal > order for speed. ::Invoke() then recurses depth-first through the chain, > which gets you back to the expected order during invocation. eats up > some stack space, but i can't think of a more elegant way. > > summary, for a bundle of delegates of type foo(int): > > (a + b + c)(42) invokes a -> b -> c. > > (a + b + c - b)(42) invokes a -> c. > > (a + b + c + a + b - (a + b))(42) > invokes a -> b -> c, not c -> a -> b. > > ever. > > i've spent quite some time until i got this right. pleaso drop me a note > if any problems arise. i remember having checked in unit tests for this, > though.
Hi Daniel, I assume I have broken correct behavior, because I have reimplemented the delegate invoke. The new implementation simply goes through the list without reverting the order. The new implementation is written in (architecture independent) IL code, and I want that code to be as simple as possible (see mono/metadata/marshal.c). So we can either provide a more complicated implementation of Invoke(), or we simply put a bit more logic into the removal code. IMO removal is not speed critical, so i would prefer that. What do you think? - Dietmar _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
