flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS]TimerEvent
Date Mon, 09 May 2016 17:27:28 GMT


On 5/9/16, 10:13 AM, "jude" <flexcapacitor@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 <joshtynjala@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 <aharui@adobe.com> wrote:
>>
>> >
>> >
>> > On 5/8/16, 2:36 PM, "Harbs" <harbs.lists@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
>> >
>> >
>> >
>>

Mime
View raw message