> And yes, inlining constants would be a good thing. I did do this with Randori(the name is bugging me now, I am going to start to call it, that other compiler :) ) so it's not that hard, I can't even commit or pull right now.
This would be down the road but I could do it. I love the way Feathers and Starling do events, they use an Event pool for one and have the data field on Event. So in my apps, you usually just had a class called MyEventType which has the constants tagged onto it. The; dispatchWithEvent(MyEventType.FOO_EVENT, true, myDataObject); Where the second parameter is bubbles. This works great, they even added functionality where the callback could receive the data in the second argument. What do you think about Event object pooling? Mike On Mon, May 18, 2015 at 5:08 PM, Alex Harui <aha...@adobe.com> wrote: > > > 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 > >
