On 5/18/15, 11:09 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>Hi, > >I'm curious as to why Strings are being used and not constants for all the >events being used in the beads to talk to strands. > >I am guessing javascript optimization? A good guess, but in reality, partially laziness, partially experimenting to see whether some events are truly needed, and mostly because I’m sort of experimenting with a different way of managing events. I never really liked the way it is done in the Flex SDK where there are dozens of Event subclasses. How often do folks actually test the type of the event? How often do folks need the payload in the event vs querying properties on the event target? In the current Flex SDK, the pattern is, if you add a new class that dispatches a new event, you have to define two classes: the new class and the event class. And if you only have one or two new event names, that’s a fair amount of overhead for two strings. Plus, folks who want to learn your new widget have to look in two places in the ASDoc. There’s a few places in FlexJS where I played around with a different pattern: define a few common Event classes and then define the event names on the classes and interfaces that actually dispatch them. If you have an Event class with no payload, and a change event class that shows what the old value is (probably one of the few things you can’t query the target for) you probably don’t need too many other events (Keyboard, Mouse, DragDrop). Also, having a constant defined for the event names (like MouseEvent.MOUSE_DOWN) is useful for AS coding, but doesn’t help the MXML coder, they still have to know the string name behind the constant. So anyway, if I were to do a cleanup, I’d add more constants to the actual classes, but I don’t know if that will fool the IDEs and whether there are advantages to having a multitude of Event subclasses that I’m not thinking of. And yes, inlining constants would be a good thing. Thoughts? -Alex
