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

P T Withington ptw at pobox.com
Sat May 3 13:18:08 PDT 2008


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?




More information about the Laszlo-dev mailing list