EventDispatcher conflict

BSiDeUp

For heaven's sake, can anyone say me, Why starling invents his own bicycles, such as EventDispatcher and so on?

For example, i have some Starling (arrrr) class, and i wont to use flex bindings. But, thanks for it, i CANT, because method names (addEventListener and so on) conflicts with native EventDispatcher!
Why not to use custom namespaces? Why not to use different names from existing? WHY?

Also, it's is really a big butthert to work with starling when you use auto-complete. I ALWAYS should select between flash.display.blablabla and starling.display.ouchmyass stuff.

Why? Anyone?)

Daniel

Haha, calm down, I know that this is annoying, but all will be good. 😉

I hated to have to re-implement the event system myself, but it just was not possible to use the original one. It's impossible to combine it with Starling, because it doesn't allow bubbling over anything else than flash.display.DisplayObject classes. I tried really hard -- it's just plain impossible.

At least there's simple fix when you're adding a classic event listener. Just write your event handler like this:

function onEvent(event:Object):void { ... }

Note the use of "Object" instead of "Event". This avoids having to import that classic event package.

As for the naming, we've discussed this for a long time in the forum, but all alternatives suck at least equally. So I decided to keep using the original names in a different package. I can tell you, though, that you'll quickly grow the habit of being more careful with selecting the right imports. After a while, your brain will automatically choose the starling variants. 😉

All in all, sorry for the troubles! But in the end, it's not as critical as it looks at first sight.

BSiDeUp

Hi, Daniel!

Thanks for your reply, but i think you're not understand situation with Bindings:
1) I have public class MySomeClass extends starling.display.Sprite
2) If i add some [Bindable] to my variables, flex automatically adds flash.events.IEventDispatcher implementation, BUT there are already methods with conflict names, such as dispatchEvent, but with wrong signatures! That's why bindings are broken:(

Do you know about ActionScript namespaces, mx_internal for example? I think you can move all Starling EventDispatcher methods to the non-public namespace, if you really want to keep its names.

joshtynjala

That would require importing and using the namespace in every class where someone wanted to call one of the Starling EventDispatcher methods. Besides being extremely confusing for new users, it would be very annoying for everyone else. It's just not a reasonable solution to work around the conflict.

Unfortunately, it looks to me like you won't be able to use [Bindable] metadata with Starling.

BSiDeUp

Don't you think that it is a bad decision to cut-off some cool functionality cause "just don't want to fix"?

Why Starling is so unfriendly?

jazuk

This may well be the best line I've ever seen on a forum..

"For heaven's sake, can anyone say me, Why starling invents his own bicycles"

joshtynjala

I think that "just don't want to fix" is a pretty poor interpretation of the situation. Daniel explained why Starling needed to reimplement EventDispatcher and why Starling uses similar names to native classes (and I've seen old threads around here that have more detailed discussion on the naming choices, if you're interested in searching). I explained why namespaces aren't an acceptable solution to your issue.

I personally don't see a way to allow Flex's bindings to work with Starling at this time. If I did, I'd happily suggest it to you and Daniel. As someone with a background in Flex, and as someone who is building components that I may add some simple MXML support to, I think that bindings would be a potentially useful tool to have in my belt.

To me, the two most promising solutions look like this:

1) Modify the compiler (it's open source, afterall) to require Starling's dispatcher instead of the native one for binding code.

2) Ask Adobe for more robustness in the Flash runtime's event system to allow customization of bubbling behavior so that it can be used outside of the native display list.

BSiDeUp

I have already implemented MXML components for Starling, but conflicts are resolved by my own framework, which makes starling stay away from bindings, btw

Seems like a second solution is the best:)

Daniel

Yes, as Josh said: I really tried finding a better solution, I just did not find one. And for the namespaces: even if we wanted to do this: you can't put a class in a custom namespace, only a method!

As for the Flex bindings: sorry, I overlooked that in your first post! Yes, that's unfortunately not working because of the already mentioned restrictions.

In any case, thanks for giving Starling a chance nevertheless! I wish you the best of luck with your project!

BSiDeUp

Hey, thanks!🙂

I will post a topic about MXML + Starling and some workarounds, caused by Starling, ASAP.

R u interested in it, btw?:)

Daniel

Thanks! If you'd like to do that, I think a small tutorial in the wiki would be great. That way, users would find it more easily than in the forum! Only if you find the time, of course. =)

JeTSpice

I'm interested too, especially in communication between MXML and Starling.

BSiDeUp

btw, MXML integration is already available as a part of my framework which you can find here:
https://github.com/Trylogic/Framework

(binaries you can find here: http://repo.trylogic.ru/content/repositories/public/ )

There no documentation yet (sorry ;( ), but this framework is 2.5 years old and was used in our company in many projects, and it's was closed, but now it's free and opensource, and i'm working hard on populating it.

There are adapter system, which allows you to port framework in any display system you want to, such as native displayList, or starling, or Genome2D, or even some 3D frameworks ( here you can find 2 adapters i wrote, for native and starling: https://github.com/Trylogic/TrylogicCore/tree/master/src/main/flex/tl/adapters )

You can explore it yourself until i found a time to document it, and feel free to contact me and ask questions (i'm online pretty often in skype: ih8fkdskype , my local time is similar to Moscow (GMT +4))

Also i'm working on GUI framework, based on TrylogicFramework, which also support changing rendering between native, starling or others), but it's not done and i'm shy to make it public yet :-[

BSiDeUp

Here you can find example from old (1.*) version of framework:

https://github.com/Trylogic/GibbetGameExample

IoC, GlobalDispatching, MXML, ViewControlling, Outlets, EventMaps, it's all in it, because there is almost no difference between old (1.*) and new(2.*) user-space code and MXML markup, so i will port this example to the new version ASAP (or, as a good training, you can do it yourself, with my help, of course)

suspendmode@gmail.com

Hey [Binding] fans. I tried to refactor starling EventDispatcher to derive from the flash one.
The results are on my github

It is not a superb impl (unfortunatly I was forced to get rid of event pool for a while) but it works with Flex SDK bindings and Starling-Demo.

So far the removeEventListeners() method has been removed too (flash EventDispatcher don't expose listeners list, i think that duplicating this list is not a good idea)

I will improve eventPhase with EventPhase.CAPTURING_PHASE in near future- as now this can be achieved easly.

pavel.fljot

Hey Daniel. Hope you're doing great)

2013 is coming to the end, maybe it's time to reconsider EventDispatcher thing again?)
Here's one example https://github.com/vaukalak/rovar-BaseEventDispatcher/blob/master/src/main/flex/by/rovar/events/BaseEventDispatcher.as

joshtynjala

Let's not start this again, please. Some members of the community recently had a very, very long discussion about EventDispatcher a month or two ago. Here's Daniel's response.

I recently opened a pull request with a partial IEventDispatcher implementation for Starling. A number of features are not supported, though. In addition to that, some other "gotchas" would make Starling harder to use for new users. There's a long description with all the details. I don't expect it to be merged for those reasons, but it was an interesting exercise. Perhaps other developers will find it useful enough to add to their own forks if they desire it strongly enough.

pavel.fljot

@Josh Tynjala

I didn't get the first part of your post. There is neither discussion regarding rewritten EventDispatcher and Event, nor Daniel's comment on that. So it's still a topic that is totally might and must be discussed.

I wouldn't look deep into your changes at the moment (respect for your efforts though!) because I see using native EventDispatcher is obviously a better option. Why don't YOU personally don't like native EventDispatcher?

joshtynjala

You're right. That discussion was about prefixing, but it is strongly related, in my opinion. I associate the two mainly because the biggest cause of people complaining about lack of prefixes is that Starling has a custom dispatcher and sometimes, Starling events and native events need to both be imported in the same class. For other classes that have conflicting names, it's less common to import both.

I don't have anything against the native EventDispatcher. I'd prefer if Starling could use it, but it has serious technical issues that make a custom event dispatcher a better choice, in my opinion. The main issue I can see off the top of my head with the class that you linked to is that bubbled events will be cloned (EventDispatcher does it internally). The garbage collection associated with that is seriously bad for performance on mobile, and Starling already has enough overhead.

A custom IEventDispatcher implementation could be a nice middle ground, since it would be compatible with code that isn't specifically aware of the Starling EventDispatcher. However, an IEventDispatcher implementation also has its own issues. Fewer issues than the native EventDispatcher as far as I discovered based on my attempts to both extend the native EventDispatcher and create a custom IEventDispatcher. With that in mind, I don't agree with the native EventDispatcher being obviously better. If you're going to push for one, I think it's better to push for an IEventDispatcher implementation instead.

ASWC

The Starling event system could inherit from Event and EventDispatcher, I've done it myself successfully in my Starling version. Won't hide that it was a big job but all it took is the will to do it.