I think we're on the same page. Please file a bug to update this
example when/if we take your init-ordering proposal.
On Dec 13, 2006, at 6:24 AM, P T Withington wrote:
On 2006-12-12, at 23:35 EST, Jim Grandy wrote:
I guess I'm not really happy with any of them, but I do think my
suggestion is the only one staying true to the actual semantics of
the language.
I think the current semantics are broken, that we should not be
creating examples that take us into that hazy area of the language.
Here's what Phil said originally:
The existing app doesn't work as intended because of an
initialization issue. The onwidth() event is fired during
initialization and this turns the view blue. The intent of the
demo is to show an event being fired when the user clicks on a
button.
My first thought was to make sure the object was fully
initialized before enabling the onwidth event. The problem is
that it will make the app look more complicated. I took an easier
route and changed the onwidth() method to only turn the view red
if the size changes from the initial value. There are lots of
ways to solve this issue and the simplest is to hard-wire the
initial width into a conditional. I changed
I think the sample code is just poorly conceived. The 'onwidth'
handler is going to fire at some indeterminate time after
setAttribute('width',n) is called, at initialization time or
later. That's the semantics of our language. It was an accident of
the ActionScript language that @width was set (and onwidth
triggered) before bgcolor was set to its initial value of red. It
is a programming error to rely on that accidental behavior, and
adding a check for the initial value is not only brittle, it
doesn't teach anything about the defined semantics of LZX.
That's why I recommended using isinited -- it may require learning
another concept, but if you are going to write code that is
sensitive to initialization time you need to use isinited. Look at
the code for baseslider, including the unit tests. To get those
unit tests to pass, you pretty much have to engineer it so that
all setter-triggered events are deferred until isinited is not
longer true. It's not easy to maintain the min<=val<=max
constraint otherwise.
This is why Henry and I want to define the ordering of events
relative to init, and if we implement our plan, your solution won't
be necessary.
If you take my solution, you finesse the issue of the hazy
(current) semantics, and the example will work correctly both
before and after we clean up those semantics. And, you don't have
to introduce two concepts at once in the example.
