On May 19, 2015 8:00 AM, "Alex Harui" <aha...@adobe.com> wrote: > > Some (many) thoughts on this: > > I considered event pooling in the current Flex SDK and have suggested > pooling other objects in people’s apps at times in the past. Some folks > claimed that instantiating lots of small objects fragmented memory and > made the Flash Garbage Collector work harder. Flex does pool item > renderers, but, IMO, more for instantiation time than GC impact. For > sure, if I was running a 3D graphic simulation I would not want hiccups on > occasion to collect garbage. > > But at least for now, the FlexJS focus is on 2D applications, so I’d want > to see if event instantiation is having a negative impact before > implementing a pool. Also, since the root event dispatching for FlexJS is > implemented within the runtimes and I believe event.target is read-only, > it is problematic to create a pool without causing other memory leaks. > > FWIW, the other way to optimize for event instantiation is to simply fire > less events. In current Flex, lots of events are fired “just-in-case". > With replaceable models and other parts in FlexJS, you should be able to > replace parts with parts that only fire the events you are actually going > to use if it turns out to be important. > > Another way to fire less events is to not use bubbling like I’ve seen some > folks do. Bubbling is an easy way to hoist an event up to a listener, but > breaks encapsulation and is the equivalent of shouting from the sidewalk > to someone on the top floor of an apartment building. Bubbling is really > intended for when the listener doesn’t know who is going to have something > to say, which is why Keyboard and Mouse events bubble, but for most custom > events, the better practice is to have each abstraction boundary dispatch > an event that doesn’t bubble and has a unique semantic meaning, and have > the one listener listen directly at the boundary. That’s like texting the > person on the top floor. Not everybody has to hear it. > > Separately, it looks like you like an API where you pass in a few > parameters instead of an event instance. The JS side already does that > and we could do that on the AS side. > > I couldn’t tell quickly whether Starling has only one Event class, but I’d > suggest we start with an Event with no data since that’s built in to the > runtimes, then a ValueChangeEvent that has oldValue/newValue and add an > EventWithData when we come up with a need for it. Also note that: > > MyClass(event.target).selectedIndex > > is type-checked by the compiler, where as > > event.data > > is probably not, so IMO, I’d recommend the former instead of passing the > payload in a data field in most cases. > > And then, unlike Starling and current Flex which has dozens of constants > declared on the Event class, I want to experiment with putting those > constants on the class that dispatches the event. Having every constant > on Event doesn’t scale well. When you get to 100’s of constants you could > be bringing in lots of strings that aren’t used and the documentation gets > unwieldy. Third-parties can’t be changing the Event class for their > components so instead of creating subclasses of Event, why not just > declare the constant on the same class that is dispatching it?
This thread is moving too fast for me. I want to concentrate on this point a bit now. The problem with declaring the constant on the same class that is dispatching it is that it would create an unnecessary compile time dependency between the class that is dispatching the event and the class that is listening to it. I think having classes loosely coupled via events is a good thing. Is it bad OO practise? I think that is debatable. But, this is truly where the power of event driven applications lies in. I usually organize my shared components in a library project, then create one or multiple app projects that compose these components as needed. I could have two different view component dispatch a 'dateRangeChanged' event with the same payload of an array of dates. In my listening class, I dont want to have to deal with having Component1.DATE_RANGE_CHANGED vs. Component2.DATE_RANGE_CHANGED vs. any other additional view components that may be built in the future. The same way, I can bubble up the event from my view component and add a listener on a ancestor higher up in the view heirarchy so that I dont have worry about the type of component that dispatched the particular event. Micro-frameworks like PureMVC, etc. try to solve this problem by creating a Notifications.as class and list every event (notification) name in that class. This would probably be the only additional dependency needed, rather than depending on the classes that dispatch the events. Thanks, Om > > Regarding where and how the JavaScript line is, I’m not quite sure what > pieces of information you are looking for, but consider this: the goal of > FlexJS is to produce an optimal HTML/JS/CSS app, not an optimal SWF. So I > will sacrifice a bit of being more like current Flex for using different > APIs to make the final cross-compiled output run better. Thus, at the > lowest level, I’m going to try to leverage HTMLElements, CSS, and > EventDispatchers built into the browsers rather than layering code on top > of it. IMO, you can always sacrifice performance and add layers on top of > your low-level, but the problem with current Flex is that there is no > low-level below the 13,000 lines of UIComponent and the nearly 200K of SWF > bytecode it is hard-coded to bring in. The composition-orientation of the > framework should allow you to build up things into higher levels where you > need them, but allow for optimization, replacement, testing, mocking, etc > of individual pieces. > > Finally, here’s the layout wiki page: > https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout > > HTH, > -Alex > > On 5/19/15, 5:41 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > >So are you saying Starling traded a bit of performance in event > >dispatching > >to get object pools? Or was is that they needed to implement bubbling of > >their own display list, so they sacrificed performance. > > > >Mike > > > >On Tue, May 19, 2015 at 8:32 AM, Kessler CTR Mark J < > >mark.kessler....@usmc.mil> wrote: > > > >> Just a side bar on this. I believe a concern about using the > >> eventdispatcher like the one in starling was that it was slower than > >>one we > >> use from flash.events. It had to do with the fact the player was > >>managing > >> the events vs using an actionscript driven one. Bumped into that when I > >> explored managing the lists of the active events and I even made single > >> serving events that would remove themselves after one call. > >> > >> > >> -Mark > >> > >> > >> -----Original Message----- > >> From: Michael Schmalle [mailto:teotigraphix...@gmail.com] > >> Sent: Tuesday, May 19, 2015 6:30 AM > >> To: dev@flex.apache.org > >> Subject: Re: [FlexJS] Event names > >> > >> NOTE: I forgot to say that in the EventManager in the component > >>framework > >> can do it; > >> > >> > >> > >> https://github.com/Gamua/Starling-Framework/blob/master/starling/src/star > >>ling/events/EventDispatcher.as > >> > >> See the method invokeEvent(), line 140. In a way, this makes the need > >>for a > >> subclassed Event obsolete, the data IS the payload which can be a > >>primitive > >> value or vo/struct class. > >> > >> The client knows what it needs. > >> > >> Mike > >> >
