[xinf] Events counter-proposal

[Nicolas Cannasse]

> hi all,
> 
> after a lot of thinking and shifting things back and forth, i've
> finally come up with a proposal for the Event model that i hope
> satisifies all. I had nearly given up, settling for either a compromise
> in-between, or going for two-different-models-at-the-same-time. But
> going thru the discussions again, i found this little hint from
> Nicolas: http://xinf.org/pipermail/xinf/2006-June/000107.html .
> 
> The trick is to use Type Parameters for functions. I didn't know this
> was possible until recently. I've tried and extended Nic's hint, and
> the result seems to be "DOM-like Events with haXe type safety". How
> does it sound like?

Not so bad ;)

Few comments on the code :
  - when creating an Event, you can set stopped to !t.bubbles
  - you can replace
       var l:List<Dynamic->Void> = listeners.get( t );
    by
       var l = listeners.get(t);
    thanks to type inference, this is exactly the same thing

The only problem is that you are "finalizing" the events a bit early.
For instance once MouseEvent is defined as :

class MouseEvent extends Event<MouseEvent>

It cannot be extended anymore.
The solution is to do the following :

class GenericMouseEvent<T> extends GenericEvent<T>
...

signature MouseEvent = GenericMouseEvent<MouseEvent>

That's even more tricky but it works, since you can later continue to
extend GenericMouseEvent :

class SubMouseEvent extends GenericMouseEvent<SubMouseEvent>
....


You could has well have :

signature Event = GenericEvent<Event>

Also, one common problem is that since there is no variance on type
parameters yet, you can't do the following :

var e : Event = new MouseEvent(...)

Since Event<MouseEvent> is not Event<Event>.

> - the "automatic delegate creation" pitfall remains- this will not work:

Yes. I tried to address this pitfall in the API I proposed (using
Listeners). The idea is to allow  addHandler  and addListener, but only
removeListener , and have addHandler return a Listener.

So this force the people that want to remove a binding to store a
Listener reference, which is exactly what we want.

> reasons. EventDispatcher is a class (includes implementation), but
> should probably be an Interface first, 

Why ?

> There is (at least) one open issue left- is the order of event
> listeners relevant? Probably yes, and EventListener should provide a
> way to register listeners with specific priorities... What'cha think?

The order should be relevant and specified. Latest registered listener
should be always called first, enabling it to stop propagation and thus
act as an event filter.

> It seems Nicolas is on holiday- so we have some time to discuss before
> he overthrows everything again :)

I'm back :)

Nicolas