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 <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 > > > > > > >
