[Mono-list] late linking & dynamic invocation ...

[Rachel Hestilow]

That isn't entirely correct.

The .NET style _is_ with a single arguments object instead of a full
signature, but it is compile-time typesafe and requires no array
unrolling.

In .NET, when data is needed to be passed into an Event, a new EventArgs
subclass is defined. This subclass defines properties for the data that
is to be passed into the callback. This means that the user doesn't have
to "de-marshal" it as Michael notes Gtk# users currently do, but it has
the distinct advantage over the full-signature approach that new data
can be added in a backwards-compatible manner. Future versions of
ControlEventArgs, for example, could add a new property without
requiring every single user to change their signatures, or without
needing to add a new event.

-- Rachel

On Fri, 2002-07-05 at 18:42, Mike Kestner wrote:
> On Fri, 2002-07-05 at 16:33, Miguel de Icaza wrote:
> 
> > Michael, the example you show is a limitation on the Gtk# code
> > generation, and has nothing to do with a limitation with the delegates. 
> > This is indeed ugly:
> 
> The code generator actually does *more* work than absolutely necessary
> in order to accomplish this *ugliness*.  It does it because this is the
> .Net model for event propagation, and Gtk# is a .Net language binding. 
> 
> I have heard so much grousing about the EventArgs usage from traditional
> Gtk users that I'm considering reworking this, or accepting a patch to
> fix it, but the reason it is done this way is to attempt to provide
> consistency with the rest of the .Net class libraries.
> 
> > While the real signature should just be:
> > 
> > void mySizeAllocateMethod (long i, long j, string name)
> > {
> > }
> > 
> > But this is not a C#/.NET limitation, it is a binding-generation
> > limitation. 
> 
> I am already generating delegates with type specific signatures in order
> to marshal the signals across from the native side. It would take less
> effort to type the events with these less generic delegates than what is
> currently being done.  I'm just not certain that is the most appropriate
> decision for the framework that Gtk# is trying to fit into.
> 
> Mike
> 
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>