flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: [FlexJS] hard coded event names
Date Tue, 23 May 2017 15:23:47 GMT

On 5/23/17, 5:48 AM, "Harbs" <harbs.lists@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,

View raw message