On May 9, 2016 1:27 PM, "Alex Harui" wrote:
>
>
> 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.
>
Inlining constants would only work correctly for str
On 5/9/16, 10:13 AM, "jude" 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 c
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 targ
On 5/9/16, 9:31 AM, "Josh Tynjala" 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?
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
On 5/8/16, 2:36 PM, "Harbs" 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. Eac
