[Laszlo-dev] Adding "ignore" arguments....

[André Bargull]

Indeed, I was talking about case 3.

There is still another problem, beside tying a method directly to an 
event, there are at least two places where you're indirectly tying it to 
an event-like structure: LzTimer and LzIdle. (see "LzTimer#addTimer(..)" 
and "LzIdle#removeCallIdleDelegates(..)" resp. "LzIdleKernel.__update()".)
So, what we actually need to do, is to change the LzDelegate-API.
New rule: every method for a delegate must accept at least one argument, 
(also see "LzDelegate#execute(..)", so that's definitely necessary.)
What to do: move the argument-length checking from 
"LzDelegate#register(..)" to the LzDelegate-constructor.

And as you said, the route 3a should be clearly discouraged, for 
instance the public API for "LzDataset#doRequest()" or "LzState#apply()" 
has been changed to get around swf9 warnings. A good example for what we 
should do, is "LzLazyReplicationManager#__LZhandleUpdate(..)". This 
method was added to be compatible to the event-system.

However, we really want to force people to update all their 
applications?! So the step from 4.0.x (or even 3.x) to 4.2 will require 
quite some work.

As an example, a call to "LzFocus#clearFocus()" needs to changed like 
so, from:
> new LzDelegate(LzFocus, "clearFocus", this, "onfoo");
to:
> new LzDelegate(this, "_handleFoo", this, "onfoo");
> + private function _handleFoo (ignore:*) {LzFocus.clearFocus();}
or to (short-form):
> new LzDelegate({_handle: function (ignore) {LzFocus.clearFocus();}}, 
> "_handle", this, "onfoo");


On 5/3/2008 10:18 PM, P T Withington wrote:
> Yes, I am not _really_ happy with the solution, but I think it is the 
> best compromise.
>
> I think there are three cases to consider:
>
> 1) You are writing a method that you will use as an event handler, e.g.,
>
>   <handler name="onfoo" method="handleOnfoo" />
>
> In this case, you have specifically declared your intent to handle a 
> sendEvent message, which by definition calls your handler method with 
> one value.  You had better accept that value, even if you ignore it; 
> otherwise, your method is not eligible to be an event handler.  So you 
> define your method:
>
>   <method name="handleOnfoo" args="value">
>     Debug.debug("onfoo sent: %w", value);
>   </method>
>
> If your handler method does not accept the sendEvent value, you will 
> get a warning and you should fix it.
>
> 2) You have a method that you want called when an event happens, e.g.,
>
>   <... onfoo="eventHappens()" ...>
>
> or
>
>   <handler name="onfoo">
>     eventHappens();
>   </handler>
>
> In this case, you are using the open tag event syntax or the handler 
> tag to make the connection between an event and a method, which 
> automatically introduces an 'event handling wrapper' with the 
> requisite argument processing, so your method can take whatever form 
> you like.  (Note:  you can declare args in the handler tag if you want 
> the sendEvent value, but if you don't the tag compiler will 
> automatically declare one ignore arg for you.)
>
> 3) You are basically cheating.  You are trying to use a method that 
> was not intended to be an event handler and tie it directly to an 
> event.  You could get away with this in the past because the runtime 
> did not care if methods were called with the correct number and type 
> of arguments.  You can't any more.  You have two choices:
>
> a) Add a nonsensical `ignore` parameter to your method to match the 
> sendEvent call (and repair all other calls of your method to pass a 
> `null` value).
>
> b) Do the right thing:  either use the <handler> tag, or if you are in 
> Javascript, your own wrapper, to mediate between the event and the 
> other method.
>
> -- 
>
> I think what you are complaining about is case 3, which was done 
> flagrantly throughout our system, probably as a premature 
> optimization.  I think we just have to fix these cases.  If we 
> _really_ think the event and handler are so central to the performance 
> of the system, then we will have to add that `ignore` parameter (3a).  
> But most likely, we can fix this cleanly by using the handler tag or a 
> javascript wrapper (3b), which should not be as objectionable.
>
> I _do_ think it is important to discourage people from taking the 3a 
> route as much as possible.  (Although I may have been lazy and done 
> this myself in a couple of places already.)
>
> On 2008-05-03, at 10:12 EDT, André Bargull wrote:
>
>> We're adding an "ignore"-argument all over the place, so that our 
>> event-system works in swf9.
>> This a really cumbersome work and some of these warnings don't really 
>> help you:
>>> WARNING @lz/gridcolumn.lzx#90: Invalid delegate: «LzCursorService 
>>> function(0)#0| kernel/swf/LzMouseKernel.as#59/21» (must accept one 
>>> argument to handle .resizer.onmouseout)
>>
>> This warning was triggered by "LzSprite#setCursor(..)" (swf), because 
>> there is this delegate:
>>> this._muDel = new LzDelegate( LzMouseKernel , 'restoreCursor', 
>>> this.owner , 'onmouseout');
>> And as "LzMouseKernel#restoreCursor()" does expect an argument (why 
>> should it!?), you get this warning.
>>
>> If we followed our current practice, we would add an 
>> "ignore"-argument to "LzMouseKernel#restoreCursor()". But that's not 
>> really convincing, to change a semi-public API (see LzCursor) just to 
>> get around this. Also think about user applications, which may have a 
>> delegate to i.e. "LzFocus#clearFocus()". They'll get a warning, 
>> because the LzFocus-API is not compatible to the event-API. So, do we 
>> need to change the public "LzFocus#clearFocus()" API because of this? 
>> Surely  not!
>>
>> Therefore, I'd like to propose:
>> - either do the function wrapping in "LzDelegate#register(..)" in 
>> swf9 automatically, but without any warnings (but consider possible 
>> performance disadvantages!)
>> - or add at compile to every function without any arguments a default 
>> "ignore"-argument, so that it is compatible to our event-system.
>>
>> Thoughts?
>
>