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.
