[xinf] Events counter-proposal

[daniel fischer]

"hank williams" <hank777 at gmail.com> (on Sun, 9 Jul 2006 12:50:28 -0400):

  > > To me, what an event means is implicitly defined by its name- and
  > > associated documentation.
  > 
  > 
  > It's not that complicated.An example: on monday I create an event in a swf
  > that I call something silly like "dbr" for door bell rang and On friday in a
  > separate swf I created another event called "dbr" but where dbr meant "done
  > breaking records" and they both had one field which was a time. For some
  > reason these two swfs need to communicate, and so you share an event
  > dispatcher between them. The two events are called "dbr" but what they mean
  > and therefore who "should" respond to them would be wrong. They have the
  > same names but different semantic meaning. The way around this is just to
  > make sure that when there is a conflict that the programmer knows "oh, I
  > have these two events with the same name but at different times I intended
  > them to mean different things so I should change one of the names"

I see what you mean now. First, i'd suggest using descriptive names. "doorBellRang" and "doneBreakingRecords" are much better name than "dbr", no? Or are you concerned about the speed of hashtable and/or memory consumption and want to keep event type names short?


  > It would just be the name and the fields and their types. This would allow
  > different languages to understand what is expected. Its kinda like a super
  > super super watered down web services.

as for the haXe part, i'm pretty confident that could be compiled out of the XML output; if not as the "master", then to compare it to such a master.

another option could be maybe a "one-line description" that the EventType would carry along (at least in debug mode)-- if you dont have the same description, you're referring to different events. But i'd prefer to simply use descriptive names :)

anyhow, i think these are just tools to ease communication between different developers in a project- a wiki could also do :)

also, if we do the global checking for name uniqueness during EventType construction, we're at least safe on the haXe side. there should be no two event types with the same name, ever. I wouldnt mind (i think) to extend the event type string with the name of the EventType class used. This way, my sample mouseDown event would have the id "xinf.ony.MouseEvent.mouseDown". If that ain't unique, you have a real communication problem :)

-dan

-- 
http://0xDF.com/
http://iterative.org/