[xinf] Events counter-proposal

[Nicolas Cannasse]

>   > First of all, has for..in a fixed order in haXe? I always assumed the
>   > order to be random.
> 
> i guess the order is undefined-- in the Test.hx i posted, it's actually FILO- so handlers attached later get the event first, which might be fine, or not. I've asked about wether enforcing a specific order (or priority) would make sense...

The order IS defined... by the iterator() implementation.
In the case of List and Array, iterators are guaranteed to iterate in
the elements order (first, second, third....).

The only differences is that :
 - in List, push() add at the beginning, add() at the end
 - in Array, shift() add at the beginning, push() at the end

>   > Then, why should one event be allowed to stop the event from being
>   > delivered to other subscribers? I know this is because of the
>   > bubbling, but I'd solve the bubbling by calling something like
>   > parent.onEvent( event ) inside a handler.
> 
> well- first, it's not about the bubbling only. the event model described doesnt inherently support bubbling (as EventDispatcher has no concept of a parent). It could do so- but somehow i wouldn't like it :)

Please note that for faster events, implementing stop propagation with
an Exception is a lot better :
  - you don't need to check e.stopped everytime
  - calling stopPropagation raise an exception, aborting further
processing in the current listener.

> But anyhow, these are implementation details and/or "higher-level" things, they don't dispute the basics here (which i regard as a good thing :) If we want, we can blow this up to be even more like DOM Events except that our EventType is a proper class (and associated string, and Event subclass) instead of simple strings, and thus we dont have to cast() or do any other dynamic untyped stuff -- with all the CAPTURE/AT_TARGET/BUBBLING stuff and so on.

Yes you could use the classname for event name :

Reflect.getClass(e).__name__.join(".")

Nicolas