It seems like getting the compiler to pull methods out of states at
compile time and put them
on the parent should be possible, so we can try to support that as a
compile time transformation.
The compiler would have to look at each child tag of a view (or
class) that it is compiling, and if it is a state or subclass of
state, it will need to
grab a copy of all of the state's methods and define them on the
parent, I guess. And complain if any method names conflict.
We probably need to do this, or be thinking about it, at the time when
we implement the compiler code which builds singleton classes
for views which have methods or constraints.
On Mon, Mar 17, 2008 at 2:25 PM, P T Withington <[EMAIL PROTECTED]> wrote:
> Oh gee! For once our bad doc saves our butt. :P
>
> OTOH, this seems to be an idiom that is used all over the place.
> There are a number of states that have 'helper' methods. The existing
> usage expects the helper method to show up in the parent (because it
> is usually helping with a constraint that will be in the parent when
> the state is applied).
>
> But there is also an improvement request that suggests that sometimes
> a state may need methods of its own. This latter, I think we can
> leave out for now as there are no use cases. But I am not so sure
> about the former.
>
>
>
> On 2008-03-17, at 14:17 EDT, David Temkin wrote:
>
> > remember that the docs as the stand say what can be included in a
> > state, and a method is not on that list. one could argue that
> > dragstate is relying on a bug. so if there is a way to rewrite
> > dragstate so it does not have a method, that could be helpful
> > (compilation rules are simpler, docs remain accurate). that would
> > presumably involve an additional external object.
> >
> >
> > On Mar 16, 2008, at 8:08 AM, P T Withington wrote:
> >
> >> Yes, remove the warning. It seems we need to allow them...
> >> although we should document that they are always there, that they
> >> don't get applied/removed like attributes.
> >>
> >> On 2008-03-16, at 10:26 EDT, Henry Minsky wrote:
> >>
> >>> Yeah I guess a state is a mixin, whose apply() method adds some
> >>> views
> >>> and installs some constraints, and the remove() method removes
> >>> them.
> >>> So we could implement that at compile time
> >>> I guess...
> >>>
> >>> So, I should remove the warning for methods in states , right?
> >>>
> >>> On Sun, Mar 16, 2008 at 9:52 AM, P T Withington <[EMAIL PROTECTED]>
> >>> wrote:
> >>>> Yeah, but it seems we need to allow methods in states, as common
> >>>> subroutines. I think we just have to document that a method in a
> >>>> state is really just a method on the parent. We need to do this at
> >>>> compile time eventually, and warn you if you are trying to
> >>>> override a
> >>>> method on the parent... hey, maybe a state is really just a mix-in?
> >>>>
> >>>>
> >>>>
> >>>> On 2008-03-16, at 09:42 EDT, Henry Minsky wrote:
> >>>>
> >>>>> Oh, my check only warns when you use method in an instance that
> >>>>> is a
> >>>>> descendant of state, not in a
> >>>>> class definition that extends state. I'll add that check.
> >>>>>
> >>>>>
> >>>>> On Sun, Mar 16, 2008 at 9:38 AM, Henry Minsky
> >>>>> <[EMAIL PROTECTED]> wrote:
> >>>>>> I'll check why the warning isn't getting generated.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Sun, Mar 16, 2008 at 8:51 AM, P T Withington <[EMAIL PROTECTED]>
> >>>>>> wrote:
> >>>>>>> We have a problem:
> >>>>>>>
> >>>>>>> dragstate has an internal method, __dragstate_get_newpos, that
> >>>>>>> is
> >>>>>>> used
> >>>>>>> by the constraints that it installs. The constraints run in the
> >>>>>>> parent, so they expect that internal method of dragstate to be
> >>>>>>> in
> >>>>>>> the
> >>>>>>> parent. It doesn't really need to be applied/removed; it just
> >>>>>>> needs
> >>>>>>> to be there for when the constraints are applied.
> >>>>>>>
> >>>>>>> I thought I had updated to include your new warning, but I am
> >>>>>>> not
> >>>>>>> getting a warning on this. It is used by the swf debugger, so
> >>>>>>> should
> >>>>>>> be triggering a warning, no?
> >>>>>>>
> >>>>>>> Anyways, we might have to re-think our policy about no methods
> >>>>>>> in
> >>>>>>> states. Not that they can't have methods, but that any
> >>>>>>> methods they
> >>>>>>> contain become methods on the parent, automatically.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2008-03-15, at 16:45 EDT, Henry Minsky wrote:
> >>>>>>>
> >>>>>>>> in base/basewindow.lzx, I moved the setDragPos method to be
> >>>>>>>> outside of
> >>>>>>>> the state, given that we will
> >>>>>>>> be phasing out support for methods inside of states.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> <state name="_windowDrag">
> >>>>>>>> <attribute name="starty" value="$once{this.y}"/>
> >>>>>>>> <attribute name="startx" value="$once{this.x}"/>
> >>>>>>>> <attribute name="ydoffset" value="this.getMouse( 'y' )"
> >>>>>>>> when="once" />
> >>>>>>>> <attribute name="xdoffset" value="this.getMouse( 'x' )"
> >>>>>>>> when="once" />
> >>>>>>>> <attribute name="y"
> >>>>>>>> value="${setDragPos('y',
> >>>>>>>> this.immediateparent.getMouse( 'y' ))}"/>
> >>>>>>>> <attribute name="x"
> >>>>>>>> value="${setDragPos('x',
> >>>>>>>> this.immediateparent.getMouse( 'x' ))}"/>
> >>>>>>>> </state>
> >>>>>>>>
> >>>>>>>> <method name="setDragPos" args="xory, mousepos"> <![CDATA[
> >>>>>>>> var newpos = mousepos - this[xory + 'doffset'];
> >>>>>>>> var diff = this[xory] - this['start' + xory];
> >>>>>>>> if (Math.abs(diff) > 3) {
> >>>>>>>> setAttribute('state', 3);
> >>>>>>>> }
> >>>>>>>> return newpos;
> >>>>>>>> ]]>
> >>>>>>>> </method>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Henry Minsky
> >>>>>>>> Software Architect
> >>>>>>>> [EMAIL PROTECTED]
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Henry Minsky
> >>>>>> Software Architect
> >>>>>> [EMAIL PROTECTED]
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Henry Minsky
> >>>>> Software Architect
> >>>>> [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Henry Minsky
> >>> Software Architect
> >>> [EMAIL PROTECTED]
> >>
> >
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
