[xinf] Events counter-proposal
daniel fischer
dan at f3c.com
Sun Jul 9 15:47:02 CEST 2006
"hank williams" <hank777 at gmail.com> (on Sun, 9 Jul 2006 09:21:57 -0400):
> 1. what does this mean:
>
> public var name(default,null) :String;
>
> what are default and null and just how do they get used.
this is the haXe style of defining a read-only property, nothing more.
"default" means to use the default getter, "null" to use "no" setter.
> 2. did you really mean this:
>
> class MouseEvent extends Event<MouseEvent> {
yes- this comes directly from Nicolas' hint. I admit its weird. It's
not recursive really (the Test.hx compiles and runs fine), it "just"
tells the parent Event<T> class to use the child class (MouseEvent) as
type parameter. I dont know how to explain this well, but it's a key
element in the typesafety of this proposal. It constrains the "type"
property of the Event<T> base class to types of class
EventType<MouseEvent>.
About the checking (and cross-language) ideas, i'll have to think more.
As hinted, we could quite easily check for uniqueness of event names by
registering them in a static list in the EventType class. As this
introduces overhead (a little runtime, more memory), i'd suggest doing
this only when a compilation flag is set. I dont think passing events
to other languages (neko/C, or AS3) should pose so much of a problem,
depending on how typesafe you want the passing to be. I will likely
also look into this-- it would be *so* sweet to bind our events
"directly" to sigc++/GObject/QT signals or the like- maybe even
typesafely :). Another issue is if this model will work well for
sending events via network connections...
There's also two more things i forgot:
* for xinf, the Event<T> class needs a "target" property. Well, this
could also be in a subclass of event (the advantage being that the
target could be a xinf.ony.Element instead of just a EventDispatcher),
but i'd suggest having it there... will (again) think more.
* For xinf, events will be funneled thru a central Queue. This is
already being done with the current xinf events (see
http://xinf.org/trac/browser/trunk/xinf/event/Event.hx). So instead of
using dispatchEvent directly, you would use postEvent which schedules
the event in the global queue for later delivery.
glad you like it. if noone raises serious issues, i'll start moving
xinf to this model and see if i can find any myself :)
does anyone know when our prophet will return from his pilgrimage (or
wherever he went)?
-dan
--
http://0xDF.com/
http://iterative.org/
More information about the xinf
mailing list