[Mono-list] [review] delegates are cascading.

[Daniel Stodden]

On Mon, 2002-03-11 at 13:57, Dietmar Maurer wrote: 
> Just some questions:
> 
> - why do we need that method_static field (if we need that info we can
> check (m_target == null))

sorry, ignore the changes to :Delegate members. it will work without
them the only interesting stuff is in :MulticastDelegate. 

there's some rubbish left in Delegate. Darn, i should have removed this
stuff to keep it more clear. 

> - how can I call those delegate constructors? All examples I have call
> the runtime provided constructor instead.

if i understand the design intentions correctly: they are never call
them directly that's what ECMA states. all compiler generated delegates
produce only stubs filled in by the runtime, which leaves construction
entirely up to mono. 

assuming .ctor does correct initialization, the C# written stuff solely
relies on MemberwiseClone() to produce chained copies. This works just
fine. 

the constructors found in Multicast/Delegate are for late binding by
scripting languages. Instead of a native pointer, these are getting a
method name string which is then looked up through .Reflection when
DynamicInvoke() is called. i must admit however that i don't understand
yet all the details, especially how exactly VB&friends are using this
functionality. MSDN VB docs give seem to provide at least some
application-level explanations but i don't feel yet really enlightened
here. 

note that compiler generated delegates don't need to be constructed in
the way the documented delegates and mcdelegates contructors suggest.
they get the native pointer on construction and don't have to rely on
runtime method lookup via strings. here, the whole thing is just a black
box. 

my problem is that my current understanding of both mono and the
reflection api is not deep enough to get the whole picture, but i think
there's some kind of redundancy here with System.Reflection.MethodBase
and this might change the constructor in future. but for C# the current
version is already sufficient. 


regards,
dns

> - Dietmar
> 
> 
> On Sat, 2002-03-09 at 10:55, Daniel Stodden wrote:
> > 
> > yay.
> > 
> > attached two lengthy patches over mono/ and mcs/
> > to make MuticastDelegate::Invoke() run smoothly over combined
> > delegates. Remove() is missing but I'll finish that over the next days.
> > 
> > i'm pretty certain it is solid, but since it changes quite 
> > bit in emit-x86..
> > please, if someone review this and tell me whether its okay to check in.
> > 
> > regards,
> > dns
> > 
> > abstract: this removes the array-based approach in favour of a reverse,
> > self-contained linked list. [emit-x86].Invoke() then recurses over the
> > contained links.
> > Why reverse? The docs require Remove() to kill any _last_ occurences of
> > a combination in the current delegate. any other method needs to
> > traverse the whole list anyways, so reversing should keep remove more
> > efficient.
> 
> 
-- 
___________________________________________________________________________
 mailto:stodden@in.tum.de