Event type naming: qualifying vs simple

I have put a lot of thought into event naming recently. In my research, I’ve seen a few developers fully qualifying their event type names. This is something I actually debated myself when writing our Media Framework, but opted not to do. The subject is debatable, so let me describe what I mean by fully qualified names and why I decided not to use them. Based on the points I outline you can make your own decision of whether to use them yourself.

What is a fully qualified event type name?
ActionScript 3 has a formal event framework where objects dispatch events and others subscribe to them and react accordingly. Each event dispatched is represented by an event object. All of the native AS3 event objects follow a formal convention of defining the types of events they can be dispatched as. This convention places a static constant representing the type name directly on their class to allow for strict typing. For example, Event.RESIZE denotes an event type of “resize” for the flash.events.Event object. The property value itself equates to a simple string. In all native AS3 objects these strings are simple and only represent the action (ex: “resize”).

Some programmers are actually fully qualifying these strings. Instead of Event.RESIZE representing the string “resize”, it is equal to “flash.events.Event.RESIZE”. Now why do this? Well say you had another event ComponentEvent which had a resize event. If you fully qualified it as well, you would have ComponentEvent.RESIZE equating to “com.dreamsocket.events.ComponentEvent.RESIZE”. Notice that now both events could be thrown from the same object and subscribed to distinctly. If they both represented the string “resize” then you would run into cases where you thought you subscribed to one event but would potentially receive both.

Why I chose not to use full qualifed names
Even though fully qualifying the string that represents the event type resolves subscription conflicts, for the most part you can resolve them just by prepending your event’s name to the type. ComponentEvent.RESIZE could be “componentResize”. In a sense this allows you to qualifying it without having a very long unique string. This is what I opted to do. One of the reasons I did this was for less advanced users and for code spiking. Simply, if you want to do things fast, it is easier just to type in a short magic string when listening to an event vs actually importing in the class and typing it out statically.

foo.addEventListener("componentResize", this.onEvent);

vs

import com.dreamsocket.events.ComponentEvent.RESIZE;
foo.addEventListener(ComponentEvent.RESIZE, this.onEvent);

Yes, this is kind of the lazy approach and one might also say its bad practice since without strict typing it could result in a “magic error”. However, I do it when I’m trying to spike an idea real fast, and I know others do it as well. I’d even venture to say designer/developer hybrids are especially prone to use it since it serves as a comfort concept they brought over from ActionScript 2. It is a practice that exists and I can’t say whether it is right or wrong.

Summary
In summary, fully qualified event types have a purpose and serve their purpose well. In our case, we wanted to take into account developers who were used to exploiting existing conventions. I feel even bad habits have advantages if it creates productivity, so the coin toss resulted in a choice not to take them away.

What are your thoughts?

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">