On 5/23/17, 5:48 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >The FlexJS style of defining constants are to define them where they are >used rather than creating new Event classes simply for defining the >constants. (i.e. Timer.TIMER rather than TimerEvent.TIMER)
This statement is a key difference that I hope will better address this issue. I'm not sure there is a 'right' answer. I don't think this is a release critical issue, but it is an interesting topic. Long term, I hope we add inlining constants to the compiler. Then we might gravitate back towards more constants for event names, but in the classes instead of new event classes. AFAICT, strings optimize better than constant lookups. The tradeoff is that folks lose developer productivity to mis-spelling or mis-capitalizing event names. I don't think there is enough pay-off to having lots of event classes with the same or similar set of properties bloating the output. It is pretty rare to have to check the type of the Event. In regular Flex the main flash.events.Event class is way overloaded. Similar for mx.events.FlexEvent. Just bringing it in brings in a bunch of potentially unused constants. I want to avoid that somehow in FlexJS. Also, even in regular Flex there were two "unofficial" categories of events: "public" events and "binding-only" events. Many uses of string event names in Flex and FlexJS are for binding-only events like "textChanged". It is rare to need to use those outside of binding expressions. Others are more commonly used from outside the class. Having constants for those "public" events are useful for AS developers but don't help the MXML developer. In MXML you still have to type the correct capitalization of the string event name. IOW, you can use Tooltip.TOOLTIP_CHANGED in AS but not in MXML. You still have to look it up to see if it is "tooltip" or "toolTip". But the compiler and code hinting should help you. But we left binding-only events as strings as it wasn't worth the cost of creating constants for everything, especially these binding-only event name strings that are often one-offs My 2 cents, -Alex
