[FlexJS]TimerEvent

[Harbs <ha...@gmail.com>]

I’m going through Flash code and converting it to FlexJS…

Is there any reason there’s no flex.utils.TimerEvent for Timer event constants? If not, I’ll add it…

Harbs

Re: [FlexJS]TimerEvent

[Alex Harui <ah...@adobe.com>]

On 5/9/16, 9:31 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>You may find that defining constants on the class that uses them doesn't
>scale well, especially with UI components. That's something I found in
>Feathers.
>
>If you or someone else creates a subclass, what to do with any constants
>on
>the base class? Should they get duplicated in the subclass? Or will users
>be forced to look up the class hierarchy to figure out where to find a
>constant? Both approaches have downsides. In Feathers, I ended up
>duplicating the constants because I saw people getting confused about
>where
>to find them. Then, I found myself occasionally forgetting to duplicate
>some constants when I created subclasses, and things just became messy and
>potentially even more confusing.

Good point about subclasses.

Still, having centralized classes of event constants causes String table
bloat.

I wonder how much trouble we would cause if the taught the compiler to
search up the class hierarchy for constants?

Thoughts?

-Alex

Re: [FlexJS]TimerEvent

[Andy Dufilie <an...@gmail.com>]

On May 9, 2016 1:27 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
> I would not be in favor of actually copying constants since it would add
> to bloat.  I'd rather work on inlining constants and looking up the chain
> at compile-time to find values to inline.
>

Inlining constants would only work correctly for strings and numbers, so
the expression type would have to be checked at compile time before
inlining. Alternatively it could simply assign a matching const in the
subclass to the value retrieved from the superclass.

Re: [FlexJS]TimerEvent

[Alex Harui <ah...@adobe.com>]

On 5/9/16, 10:13 AM, "jude" <fl...@gmail.com> wrote:

>If we're rethinking the Event class is there a way to prevent the loss of
>strong typing with currentTarget and target? Could we have a
>event.targetType or event.currentTargetType property? Even maybe a
>valueType. Then you could at compile time or runtime check that the value
>that is set in the target, currentTarget or data property are of the
>aforementioned type.

In theory, it might be possible with the new -allow-subclass-overrides
option.  Feel free to try it.

>
>I suppose if we're in charge of the compiler then could we duplicate the
>constants all the way to the chain? So all constants on UIComponent would
>be copied to Button that extends UIComponent.

I would not be in favor of actually copying constants since it would add
to bloat.  I'd rather work on inlining constants and looking up the chain
at compile-time to find values to inline.

>
>I like simplifying events but with something like an AcceleratorEvent
><http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/
>events/AccelerometerEvent.html>
>instance you'll get the 4 Number fields for X, Y, Z and timestamp. Would
>creating an object with those four properties cost more? From what I've
>read creating objects can be expensive. OTOH if everything is a generic
>Event you can setup an object pool and reuse events.

For Flash or JS?  In Flash, Event pooling is tricky because re-dispatches
call clone() so often the pooled item never gets sent, its clone does,
which doesn’t save you anything.

>
>If it's possible though, there are other methods besides events that might
>be faster like signals or function hooks. Where you setup functions to
>call
>without creating any event objects. If there were a way to allow for both
>event listeners or signal listeners that would let people choose the best
>choice for them.

You can always add a different communication subsystem for some other part
of the framework.  We are currently leveraging DOM events because they are
built into both Flash and JS runtimes.

-Alex

>
>myEventDispatcher.addSignalListener(myHandler);
>funtction myHandler(myParameter:Object):void {}
>
>On Mon, May 9, 2016 at 11:31 AM, Josh Tynjala <jo...@gmail.com>
>wrote:
>
>> You may find that defining constants on the class that uses them doesn't
>> scale well, especially with UI components. That's something I found in
>> Feathers.
>>
>> If you or someone else creates a subclass, what to do with any
>>constants on
>> the base class? Should they get duplicated in the subclass? Or will
>>users
>> be forced to look up the class hierarchy to figure out where to find a
>> constant? Both approaches have downsides. In Feathers, I ended up
>> duplicating the constants because I saw people getting confused about
>>where
>> to find them. Then, I found myself occasionally forgetting to duplicate
>> some constants when I created subclasses, and things just became messy
>>and
>> potentially even more confusing.
>>
>> That wasn't for event constants in Feathers, though. It was for other
>>types
>> of constants that the components used. However, I think this advice
>>still
>> applies.
>>
>> In Starling, the main Event class works similarly to what you describe.
>>It
>> has a data property that can be used to pass pretty much anything with
>>the
>> event. In Feathers, I ended up creating a FeathersEventType class that
>> defined common event constants so that I could dispatch
>> starling.events.Event instances. This proved to be a nice approach. I
>>could
>> see something like a FlexEventType class for constants, or more specific
>> names for different categories of event constants.
>>
>> - Josh
>>
>> On Sun, May 8, 2016 at 10:36 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> >
>> >
>> > On 5/8/16, 2:36 PM, "Harbs" <ha...@gmail.com> wrote:
>> >
>> > >I’m going through Flash code and converting it to FlexJS…
>> > >
>> > >Is there any reason there’s no flex.utils.TimerEvent for Timer event
>> > >constants? If not, I’ll add it…
>> >
>> > Well, one thing I wanted to do differently in FlexJS vs Flex was have
>> > fewer event classes.  Each Event subclass takes up download and
>> > initialization time.  So my plan for FlexJS was to only have "generic"
>> > event classes like Event and ValueEvent and ValueChangeEvent and
>> hopefully
>> > fewer other subclasses where the number of other payload properties
>>and
>> > names of those payload properties would be important, and specify
>> > constants in the classes that generate the event.  So, in short: no
>> > TimerEvent class, but you are correct that we don't have a const to
>>use
>> so
>> > we should add a TIMER constant to the Timer class itself (and use it
>> > within).
>> >
>> > More detail:
>> >
>> > In Flex, there are lots of Event subclasses, with Event constants, and
>> > other properties, but often, those properties are not really needed on
>> the
>> > event object.  Most folks can safely take a CHANGE event and examine
>>the
>> > selectedItem in the DataGrid.  It wastes cycles to copy the
>>selectedItem
>> > into the Event and pass it around if you can just check the
>> > event.target.selectedItem.  Sure, it isn't a lot of cycles, but it
>>might
>> > all add up, especially when events are flying around like crazy at
>> > startup.  So, in FlexJS, I would like to try not copying properties to
>> the
>> > Event object if it is "stable".
>> >
>> > Now, the oldValue of a ValueChangeEvent is not "stable" because there
>>is
>> > no way to examine the event.target to find the oldValue, so yes, you
>>have
>> > to at least have an Event subclass that sports an oldValue property,
>>and
>> > it makes sense to have the "newValue" in there as well.
>> >
>> > Bunches of other event classes just have zero or one property.  So in
>> > FlexJS I added a ValueEvent which has a generic value property typed
>>as
>> > Object.  Timer maybe should dispatch this Event instead and include
>>the
>> > currentTime, since that is also "unstable".  By the time your code
>>gets
>> > around to examining the time in response to the event, the value may
>>be
>> > incorrect.
>> >
>> > Anyway, I'm not going to be strict about this.  The usability of
>>having
>> an
>> > Event with a currentTime instead of a generic "value" property may be
>> > worth the extra download and startup time.  I just wanted to see how
>>the
>> > pattern looked and felt to see if we could save a few bytes and cycles
>> > here and there.  In the regular Flex SDK, it is as big and slow as it
>>is
>> > partly because we kept opting to take the minimal size hit until we
>>took
>> > the hit so many times it added up to something.  I'd like to avoid
>>that
>> in
>> > FlexJS if possible, but the APIs also have to be easy to work with.
>> >
>> > -Alex
>> >
>> >
>> >
>>

Re: [FlexJS]TimerEvent

[jude <fl...@gmail.com>]

If we're rethinking the Event class is there a way to prevent the loss of
strong typing with currentTarget and target? Could we have a
event.targetType or event.currentTargetType property? Even maybe a
valueType. Then you could at compile time or runtime check that the value
that is set in the target, currentTarget or data property are of the
aforementioned type.

If you take a performance hit for looking up the class hierarchy to find
constants what if they're moved to a separate class entirely like
UIComponentConstants. The problem with that is that every class that
extends UIComponent would have to add constants there or in their own
ButtonConstants class.

I suppose if we're in charge of the compiler then could we duplicate the
constants all the way to the chain? So all constants on UIComponent would
be copied to Button that extends UIComponent.

I like simplifying events but with something like an AcceleratorEvent
<http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/AccelerometerEvent.html>
instance you'll get the 4 Number fields for X, Y, Z and timestamp. Would
creating an object with those four properties cost more? From what I've
read creating objects can be expensive. OTOH if everything is a generic
Event you can setup an object pool and reuse events.

If it's possible though, there are other methods besides events that might
be faster like signals or function hooks. Where you setup functions to call
without creating any event objects. If there were a way to allow for both
event listeners or signal listeners that would let people choose the best
choice for them.

myEventDispatcher.addSignalListener(myHandler);
funtction myHandler(myParameter:Object):void {}

On Mon, May 9, 2016 at 11:31 AM, Josh Tynjala <jo...@gmail.com> wrote:

> You may find that defining constants on the class that uses them doesn't
> scale well, especially with UI components. That's something I found in
> Feathers.
>
> If you or someone else creates a subclass, what to do with any constants on
> the base class? Should they get duplicated in the subclass? Or will users
> be forced to look up the class hierarchy to figure out where to find a
> constant? Both approaches have downsides. In Feathers, I ended up
> duplicating the constants because I saw people getting confused about where
> to find them. Then, I found myself occasionally forgetting to duplicate
> some constants when I created subclasses, and things just became messy and
> potentially even more confusing.
>
> That wasn't for event constants in Feathers, though. It was for other types
> of constants that the components used. However, I think this advice still
> applies.
>
> In Starling, the main Event class works similarly to what you describe. It
> has a data property that can be used to pass pretty much anything with the
> event. In Feathers, I ended up creating a FeathersEventType class that
> defined common event constants so that I could dispatch
> starling.events.Event instances. This proved to be a nice approach. I could
> see something like a FlexEventType class for constants, or more specific
> names for different categories of event constants.
>
> - Josh
>
> On Sun, May 8, 2016 at 10:36 PM, Alex Harui <ah...@adobe.com> wrote:
>
> >
> >
> > On 5/8/16, 2:36 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> > >I’m going through Flash code and converting it to FlexJS…
> > >
> > >Is there any reason there’s no flex.utils.TimerEvent for Timer event
> > >constants? If not, I’ll add it…
> >
> > Well, one thing I wanted to do differently in FlexJS vs Flex was have
> > fewer event classes.  Each Event subclass takes up download and
> > initialization time.  So my plan for FlexJS was to only have "generic"
> > event classes like Event and ValueEvent and ValueChangeEvent and
> hopefully
> > fewer other subclasses where the number of other payload properties and
> > names of those payload properties would be important, and specify
> > constants in the classes that generate the event.  So, in short: no
> > TimerEvent class, but you are correct that we don't have a const to use
> so
> > we should add a TIMER constant to the Timer class itself (and use it
> > within).
> >
> > More detail:
> >
> > In Flex, there are lots of Event subclasses, with Event constants, and
> > other properties, but often, those properties are not really needed on
> the
> > event object.  Most folks can safely take a CHANGE event and examine the
> > selectedItem in the DataGrid.  It wastes cycles to copy the selectedItem
> > into the Event and pass it around if you can just check the
> > event.target.selectedItem.  Sure, it isn't a lot of cycles, but it might
> > all add up, especially when events are flying around like crazy at
> > startup.  So, in FlexJS, I would like to try not copying properties to
> the
> > Event object if it is "stable".
> >
> > Now, the oldValue of a ValueChangeEvent is not "stable" because there is
> > no way to examine the event.target to find the oldValue, so yes, you have
> > to at least have an Event subclass that sports an oldValue property, and
> > it makes sense to have the "newValue" in there as well.
> >
> > Bunches of other event classes just have zero or one property.  So in
> > FlexJS I added a ValueEvent which has a generic value property typed as
> > Object.  Timer maybe should dispatch this Event instead and include the
> > currentTime, since that is also "unstable".  By the time your code gets
> > around to examining the time in response to the event, the value may be
> > incorrect.
> >
> > Anyway, I'm not going to be strict about this.  The usability of having
> an
> > Event with a currentTime instead of a generic "value" property may be
> > worth the extra download and startup time.  I just wanted to see how the
> > pattern looked and felt to see if we could save a few bytes and cycles
> > here and there.  In the regular Flex SDK, it is as big and slow as it is
> > partly because we kept opting to take the minimal size hit until we took
> > the hit so many times it added up to something.  I'd like to avoid that
> in
> > FlexJS if possible, but the APIs also have to be easy to work with.
> >
> > -Alex
> >
> >
> >
>

Re: [FlexJS]TimerEvent

[Josh Tynjala <jo...@gmail.com>]

You may find that defining constants on the class that uses them doesn't
scale well, especially with UI components. That's something I found in
Feathers.

If you or someone else creates a subclass, what to do with any constants on
the base class? Should they get duplicated in the subclass? Or will users
be forced to look up the class hierarchy to figure out where to find a
constant? Both approaches have downsides. In Feathers, I ended up
duplicating the constants because I saw people getting confused about where
to find them. Then, I found myself occasionally forgetting to duplicate
some constants when I created subclasses, and things just became messy and
potentially even more confusing.

That wasn't for event constants in Feathers, though. It was for other types
of constants that the components used. However, I think this advice still
applies.

In Starling, the main Event class works similarly to what you describe. It
has a data property that can be used to pass pretty much anything with the
event. In Feathers, I ended up creating a FeathersEventType class that
defined common event constants so that I could dispatch
starling.events.Event instances. This proved to be a nice approach. I could
see something like a FlexEventType class for constants, or more specific
names for different categories of event constants.

- Josh

On Sun, May 8, 2016 at 10:36 PM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 5/8/16, 2:36 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >I’m going through Flash code and converting it to FlexJS…
> >
> >Is there any reason there’s no flex.utils.TimerEvent for Timer event
> >constants? If not, I’ll add it…
>
> Well, one thing I wanted to do differently in FlexJS vs Flex was have
> fewer event classes.  Each Event subclass takes up download and
> initialization time.  So my plan for FlexJS was to only have "generic"
> event classes like Event and ValueEvent and ValueChangeEvent and hopefully
> fewer other subclasses where the number of other payload properties and
> names of those payload properties would be important, and specify
> constants in the classes that generate the event.  So, in short: no
> TimerEvent class, but you are correct that we don't have a const to use so
> we should add a TIMER constant to the Timer class itself (and use it
> within).
>
> More detail:
>
> In Flex, there are lots of Event subclasses, with Event constants, and
> other properties, but often, those properties are not really needed on the
> event object.  Most folks can safely take a CHANGE event and examine the
> selectedItem in the DataGrid.  It wastes cycles to copy the selectedItem
> into the Event and pass it around if you can just check the
> event.target.selectedItem.  Sure, it isn't a lot of cycles, but it might
> all add up, especially when events are flying around like crazy at
> startup.  So, in FlexJS, I would like to try not copying properties to the
> Event object if it is "stable".
>
> Now, the oldValue of a ValueChangeEvent is not "stable" because there is
> no way to examine the event.target to find the oldValue, so yes, you have
> to at least have an Event subclass that sports an oldValue property, and
> it makes sense to have the "newValue" in there as well.
>
> Bunches of other event classes just have zero or one property.  So in
> FlexJS I added a ValueEvent which has a generic value property typed as
> Object.  Timer maybe should dispatch this Event instead and include the
> currentTime, since that is also "unstable".  By the time your code gets
> around to examining the time in response to the event, the value may be
> incorrect.
>
> Anyway, I'm not going to be strict about this.  The usability of having an
> Event with a currentTime instead of a generic "value" property may be
> worth the extra download and startup time.  I just wanted to see how the
> pattern looked and felt to see if we could save a few bytes and cycles
> here and there.  In the regular Flex SDK, it is as big and slow as it is
> partly because we kept opting to take the minimal size hit until we took
> the hit so many times it added up to something.  I'd like to avoid that in
> FlexJS if possible, but the APIs also have to be easy to work with.
>
> -Alex
>
>
>

Re: [FlexJS]TimerEvent

[Alex Harui <ah...@adobe.com>]

On 5/8/16, 2:36 PM, "Harbs" <ha...@gmail.com> wrote:

>I’m going through Flash code and converting it to FlexJS…
>
>Is there any reason there’s no flex.utils.TimerEvent for Timer event
>constants? If not, I’ll add it…

Well, one thing I wanted to do differently in FlexJS vs Flex was have
fewer event classes.  Each Event subclass takes up download and
initialization time.  So my plan for FlexJS was to only have "generic"
event classes like Event and ValueEvent and ValueChangeEvent and hopefully
fewer other subclasses where the number of other payload properties and
names of those payload properties would be important, and specify
constants in the classes that generate the event.  So, in short: no
TimerEvent class, but you are correct that we don't have a const to use so
we should add a TIMER constant to the Timer class itself (and use it
within).

More detail:

In Flex, there are lots of Event subclasses, with Event constants, and
other properties, but often, those properties are not really needed on the
event object.  Most folks can safely take a CHANGE event and examine the
selectedItem in the DataGrid.  It wastes cycles to copy the selectedItem
into the Event and pass it around if you can just check the
event.target.selectedItem.  Sure, it isn't a lot of cycles, but it might
all add up, especially when events are flying around like crazy at
startup.  So, in FlexJS, I would like to try not copying properties to the
Event object if it is "stable".

Now, the oldValue of a ValueChangeEvent is not "stable" because there is
no way to examine the event.target to find the oldValue, so yes, you have
to at least have an Event subclass that sports an oldValue property, and
it makes sense to have the "newValue" in there as well.

Bunches of other event classes just have zero or one property.  So in
FlexJS I added a ValueEvent which has a generic value property typed as
Object.  Timer maybe should dispatch this Event instead and include the
currentTime, since that is also "unstable".  By the time your code gets
around to examining the time in response to the event, the value may be
incorrect.

Anyway, I'm not going to be strict about this.  The usability of having an
Event with a currentTime instead of a generic "value" property may be
worth the extra download and startup time.  I just wanted to see how the
pattern looked and felt to see if we could save a few bytes and cycles
here and there.  In the regular Flex SDK, it is as big and slow as it is
partly because we kept opting to take the minimal size hit until we took
the hit so many times it added up to something.  I'd like to avoid that in
FlexJS if possible, but the APIs also have to be easy to work with.

-Alex