why the new delegate system not adding parameter to callback?

[wallabie]

Is there a good reason why the new delegate system not adding parameters to the CallBack() function ?  Looking through the code to figure out how the parameters are being supported, one has to say that it is definitely not easy to follow.  Can you please explain what the reason for not adding the parameters to the callBack function? 

[drjeats]

Are you talking about the fact that EventDelegates no longer take parameter that's a reference to the GameObject or UIWidget that generated an event?

I'm assuming the goal was to not have to make a dozen different callback types each with different method signatures. Instead of sending, say, a UIInput as the first parameter to the callback, you just read the static variable UIInput.current.

ArenMook posted a video recently demonstrating upcoming support for callback arguments set via the inspector, which is arguably (pun intended) more interesting and useful. You can also always set a first "sender" argument to the widget dispatching the event if polling a static variable really rubs you the wrong way.

If that's not what you meant, then... uh... Nevermind.   

[ArenMook]

Callback is a void delegate type. It always has been. It's there to make it possible to have anonymous delegates, as well as to speed up the delegate calls if there are no parameters. It's basically the "fast path", "optimized" approach that's used if possible.

[wallabie]

@drjeats, not really what I meant. 

What I am trying to do is to try to understand how the EventDelegate with params system works.  In most delegate with params situations in C# i've seen,  it's quite common practice to create a delegate that takes params.  Instead of CallBack(), it's CallBack(params object[] args).   I thought this was how it was going to be implemented, but could not find anything like this in the new implementation.  Still trying to figure out how it works.