Our understanding of JS2 is that, dynamic or static class, a method is
a const property. You can't change it. Making your class dynamic
means that it can be subclassed and that subclasses can override and
add methods.
Alternatively, JS2 still has prototype properties. You can say:
class foo {
prototype function bar () { barbody }
}
fu = new foo;
fu.bar = function wunderbar () { wunderbody }
So, that is a partial out if you _have_ to be able to smash methods at
runtime. But:
1) We don't know if the AS dialect of JS2 supports this
2) We don't know if you are permitted to use `super` in a prototype
function (I fear not)
3) We'll need to do more analysis at compile time to correctly declare
the parent method if the state has a method of the same name
4) There is a performance penalty for using prototype functions,
because they must be looked up at run time.
As Henry points out, the last ditch is to have the compiler do
something like:
class foo {
function bar () {
if (this.state.applied) {
wunderbody
} else {
barbody
}
}
etc., worrying about control flow and return values... Yech!
On 2008-02-21, at 13:02 EST, David Temkin wrote:
Wouldn't this work on a dynamic class as opposed to a sealed class?
Not good if this can't be made to work at all.
On Feb 21, 2008, at 8:45 AM, Henry Minsky wrote:
Going forward, we cannot really be messing with methods in the same
dynamic way we have been up to this point,
because we're not free to define or delete them at runtime in swf9,
nor many other runtimes we might want to
target.
We should assume that methods are things that only can be defined
at compile time, and cannot be deleted.
If you define a method inside a state, that will have to be
equivalent to defining it outside of the state.
I suppose if we were masochistic we could make the compiler merge
methods at compile time with some kind
of dispatch flag to say which method body code to run depending on
if a state is applied, but that doesn't
seem maintainable to me.
On Thu, Feb 21, 2008 at 11:16 AM, David Temkin <[EMAIL PROTECTED]
> wrote:
The docs say:
Everything within a <state> tag acts as if it were written inside
the parent when the state is applied. States can contain
attributes, methods, and other nodes.
This is a clean conceptual model, IMHO. No exceptions.
I would expect elements within the state to be added/removed when
the state is applied/removed. I would not expect elements that are
not specified within in the state (e.g., other attributes, other
methods, other views) to be affected by apply/remove of the state.
(That's what enables what Sarah calls "side effects" below).
I *am* surprised that methods added when a state is applied aren't
removed when the state is removed -- if that is in fact what Sarah
is saying below. That sounds like a bug.
Regarding the proximate issue mentioned by Tucker: Sounds like a
bug in the SWF debugger, and not a general problem with dragstate.
On Feb 21, 2008, at 7:21 AM, Sarah Allen wrote:
Interesting question! cc'ing Laszlo-user list, since LZX coders on
there might have some thoughts on this, or at least be interested
in the details of how states work and whether that should be
changed in the future. I did a little experimentation (see below)
to remind myself how states work, and recall a little history of
how we got to where we are. I do like the current behavior (the
convenience of implementing dragstate and friends), but I do admit
that some of the nuances of states can be confusing and I don't
know if they are clearly documented.
The question is: should contraints that are overridden when a
state is applies be "put back" when a state is removed?
Conceptually when you apply a state, a bunch of stuff is added,
and when you remove it that stuff is removed; however, states are
allowed to have side effects, when attributes are modified by a
state they stay modified. So, attributes and methods when applied
remain as side effects; however, views and events are temporal and
get removed. Way back in LPS v1, Adam Wolff and I decided that
constraints are conceptually like attribute values, even if their
implementation is more like an event; which is why we have the
behavior we do today.
In an abstract sense, it feels like a bug that when a state is
removed, you don't just put everything back the way it was. If
you look at this simple example, that might be your expectation:
<canvas>
<checkbox id="cbox" text="Show"
x="10" y="10" />
<state apply="${cbox.value}">
<view bgcolor="blue" x="5" y="30"
width="150" height="150" />
</state>
</canvas>
However, it is a powerful feature of states that you are allowed
to leave a side-effect behind (which is really what enables the
simplicity of dragstate and related coding patterns.) If you
change the value of an attribute, it stays that way. In the
following example, after clicking on the checkbox twice to turn it
on and off again, the value of the attribute "t" is 10, not it's
original value "4"
<canvas>
<simplelayout/>
<attribute name="t" value="4"/>
<text text="${canvas.t}"/>
<checkbox id="cbox" text="Show"
x="10" y="10" />
<state apply="${cbox.value}">
<attribute name="t" value="10"/>
<view bgcolor="blue" x="5" y="30"
width="150" height="150" />
</state>
</canvas>
Now, I wonder what happens with a method. In the example below,
you will see that if I toggle the checkbox on and back off, the
state's method remains, just like an attribute.
<canvas debug="true">
<simplelayout/>
<attribute name="t" value="4"/>
<text text="${canvas.t}"/>
<checkbox id="cbox" text="Show"
x="10" y="10" />
<state apply="${cbox.value}">
<attribute name="t" value="10"/>
<view bgcolor="blue" x="5" y="30"
width="150" height="150" />
<method name="doSomething">
Debug.write('new');
</method>
</state>
<button onclick="canvas.doSomething()">doSomething</button>
<method name="doSomething">
Debug.write('orginal');
</method>
</canvas>
Events, get added and removed like views. In the example below,
you end up with two events when the state is applied, then just
the original event when the state is removed.
<canvas debug="true">
<simplelayout/>
<attribute name="t" value="4"/>
<text text="${canvas.t}"/>
<checkbox id="cbox" text="Show"
x="10" y="10" />
<state apply="${cbox.value}">
<attribute name="t" value="10"/>
<view bgcolor="blue" x="5" y="30"
width="150" height="150" />
<handler name="onmousedown" reference="LzGlobalMouse">
Debug.write('new');
</handler>
</state>
<button onclick="canvas.doSomething()">doSomething</button>
<handler name="onmousedown" reference="LzGlobalMouse">
Debug.write('original');
</handler>
</canvas>
P T Withington wrote:
As part of fixing LPP-631 in r8032, states now remove constraints
that they override when applied, and they _restore_ those
constraints when removed. This breaks dragging and resizing of
the swf debugger window!
The swf debugger starts out with its dimensions defaulted to a
percentage of the canvas. Percentage values are constraints.
This is nifty, because if you resize your browser window, the
debugger window nicely resizes too.
But if you try to drag or resize the window, the drag or resize
state gets applied, the window tracks the mouse, but when you let
go of the mouse, the state gets removed and the previous
percentage constraints are reinstalled, snapping the window back
to its starting position.
My question: Is this a bug in states? Should they _not_ restore
constraints they removed? Is this a bug in drag/resize states?
Should they be overriding the base state behavior of restoring
constraints? Or, is this just a bug in the swf debugger? Should
it only size to the canvas initially and not respond to canvas
changes? Or should it be improved to track the canvas until it
is resized or dragged?
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
