[Mono-list] Re: [Mono-bugs] Hi.

[Dietmar Maurer]

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