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 [EMAIL PROTECTED] ([EMAIL PROTECTED]) {
try {
`setter.text()`
} finally {
if (`! setter.(@event == 'true')`) {
if (this['[EMAIL PROTECTED]'] && [EMAIL PROTECTED]'ready']) {
this.sendEvent('[EMAIL PROTECTED]', [EMAIL PROTECTED]);
}
}
}
}
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.
