[xinf] Events counter-proposal

[hank williams]

On 7/9/06, daniel fischer <dan at f3c.com> wrote:
>
> "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?



I would *never* use a name like dbr. It was just for example purposes.

But it is still very possible to have a descriptive name that conflicts with
another descriptive name. And when it happens you will be totally confused.

  > 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 :)



Yeah, in lots of circumstances this wont matter, but in terms of long term
code reusability its helpful. I'm just saying I would like the same conflict
checking benefit that I have when compiling all at once, as when separate
pieces are on libraries or other languages.

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 :)


Yeah, thats actually a really good idea. Though one issue occurs to me is
how *do* you tell it that these two things, even though their roots are
different *are* the same event? You would then be at the point of having to
define some common namespace. Hmmm...

Hank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://xinf.org/pipermail/xinf/attachments/20060709/e2c95ee2/attachment.html