In SWF9, you can assign functions to properties dynamically, but they aren't
real methods. The big difference is that you
cannot call "super" in them, so you cannot override a method that way. Same
for setters, you can't add a new setter which overrides and then calls
super(). Currently, the swf9 implementation does use properties
dynamically for setters, and this is broken because that code will not work
where people override setters and call super(). It will be
fixed as part of Tucker's change which will define everything (setters,
event handlers, methods) as methods at compile time.
On Thu, Feb 21, 2008 at 1:02 PM, David Temkin <[EMAIL PROTECTED]>
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]
>
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
