Well, I confess I was going from the description of the app rather
than from having looked at it recently, and the description in this
thread suggested merely that the color should not switch from one to
the other during initialization. I still think having a test like
that in the onwidth handler is not ideal, but I'm even more eager to
move on to some other (any other!) topic, so please just do whatever
Tucker thinks is best.
jim
On Dec 13, 2006, at 12:03 PM, P T Withington wrote:
I wasn't 'testing for a nothing-special value that happens to be
the initial value'. In my example the box is blue when it is wider
than 100px, red when it is 100px or narrower. You can pick any
initial value you want and it will take on the appropriate color.
You can push the bigger or smaller button and it will change size
and color. It seemed like a reasonably good way to demonstrate
listening to a setter event. It could even have a follow-on lesson
to show how you can implement the same effect more concisely with a
constraint:
bgcolor="${width>100?blue:red}"
Are you saying that for pedagogical reasons we should leave the
example broken for now?
On 2006-12-13, at 13:28 EST, Jim Grandy wrote:
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.
