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

[Dietmar Maurer]

On Tue, 2002-03-12 at 11:22, Daniel Stodden wrote:
> 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. 

I have just commited your changes (slightly modified)
> 
> > - 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. 

I already added the method_info field. Unfortunately the docs are wrong,
and the MS implementation sets method_info for all kinds of delegates
(not only for static methods). I am just working on that to make it
compatible to MS.

BTW: we also need multicast support in mint, and some test cases -
interested?

- Dietmar