[Laszlo-dev] RFC: Proposal for setter API change

[André Bargull]

On 10/2/2008 8:57 PM, P T Withington wrote:
> On 2008-10-02, at 10:55EDT, André Bargull wrote:
> 
>>>
>>> In the default event system, what you get if you don't write a 
>>> custom  setter, sends an event every time you call setAttribute.  It 
>>> does  _not_ make any optimization to not send events if you happen to 
>>> set an  attribute to a value it already has.
>>>
>> A side note for the interested reader:
>> It's possible to turn on manually this optimization if you pass as the 
>> third argument to "setAttribute()" ?true?, e.g.
>> foo.setAttribute("text", "hello world!", true)
>> (That way the setter is not called when the value did not change.)
> 
> My head hurts trying to process that logic.  Too many negatives.
> 
> This seems like an incredibly dangerous optimization, because if you 
> have a custom setter, how can the generic code know whether or not the 
> value 'changed'?  E.g., suppose the custom setter ensures your value is 
> in a particular range or rounded to a particular granularity?
> 
> When did setAttribute grow this featureXXXXXXXbug?  I don't recall 
> seeing an API review for this.

It's there since 4.0.5

> 
> And, I wonder, does the compiler know about this featureXXXXXXXbug where 
> it inlines calls to setAttribute?

Yes, it knows about this feature. There is even special code to compile 
away this feature if you call setAttribute() with only two arguments.


>> When do you send the event?
>> 1. after setting the property
>> a) requires code analysis
>> b) likely to be more natural
>> c) property may be have any name -> problem...
>> 2. at the end of the setter
>> a) what happens if the user places return statement in the setter? [1]
>> b) or an error was thrown?
>>
>> When do you send no event?
>> 1. if you override a setter
>> a) because the super-setter should handle this,
>> b) but if the super-setter is not called? (by purpose or 
>> unintentionally?)
>>
> 
> The tag compiler could compile setters as follows (using pseudo-e4x and 
> `` to mean compile-time substitution):
> 
>  function $lzc$set_`setter. at name` (`setter. at args`) {
>     try {
>       `setter.text()`
>     } finally {
>       if (`! setter.(@event == 'true')`) {
>         if (this['on`setter. at name`'] && this.on`setter. at name`['ready']) {
>           this.sendEvent('on`setter. at name`', this.`setter. at name`);
>         }
>       }
>     }
>   }
> 
> Since <setter> is a brand new feature, IWBN to make this change in its 
> semantics now.
> 

How much performance does it cost to establish a try-finally block in 
the runtimes?

And still open:
 >> When do you send no event?
 >> 1. if you override a setter
 >> a) because the super-setter should handle this,
 >> b) but if the super-setter is not called? (by purpose or
 >> unintentionally?)

I think this is quite hard to handle. Maybe it's easier to just add the 
possibility to auto-generate events. So for the time being, if 
"events='true'" on a setter-tag, the event-sending code will be added by 
the compiler. If "events='false'" or not specified, do nothing.