On 5/9/16, 10:13 AM, "jude" <flexcapaci...@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 <joshtynj...@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 <aha...@adobe.com> wrote: >> >> > >> > >> > On 5/8/16, 2:36 PM, "Harbs" <harbs.li...@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 >> > >> > >> > >>
