OK, we're not, and we can agree to disagree. I think now and in the
future, testing for a nothing-special value that happens to be the
initial value is bad pedagogy.
jim
On Dec 13, 2006, at 10:16 AM, P T Withington wrote:
We're not quite on the same page. My update can be put in now, and
the example will be immune to init ordering while still conveying
its point. It will work now, and it will work later. Since it
does not work now, I propose that Phil take my change now.
[A separate issue would be to create a test case that shows how
init order is currently broken. By coincidence this example in its
present form is such a case, but that is not its purpose.]
On 2006-12-13, at 12:26 EST, Jim Grandy wrote:
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.
