On Tue, May 19, 2015 at 11:19 AM, Alex Harui <aha...@adobe.com> wrote:
> > > On 5/19/15, 10:33 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > >>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? > > > > > >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. > > Well, the notion of “every” doesn’t sound scalable to me, but you are > right about the class dependency. However, do you really run into two > components dispatching the same event with different meanings in real life? > Same event with same meanings - yes. Different meanings - not sure I've had that. I guess that would be a problem, wouldn't it? This kind of behavior is more common in the case of shared mobile + web app projects. A DateChooser in web app is a completely different from a DateChooser in a mobile app and not just the same component with two different skins. Thanks, Om > > I wonder if there is some way we can define constants on an Interface. > > -Alex > >
