Best Practices: Default functions, custom events, & methods?

Hello again,

I'm putting together a fairly generic and flexible object that inherits from Y.Base and I have a general question about what's considered best practices regarding default actions on custom events.

Let's say that I have an object that represents an abstract collection of child objects. It fires custom events when you add and remove elements, as well as a few other cases. My specific question is this:

* Should the add (for example) member function add the element to the collection, then fire an event indicating that the object has been added, OR
* Should the add member function fire a custom event, the default action of which is to add the object to the collection?

The first option keeps the code simple and allows for straightforward inheritance (if I wanted to make specialized collection types later on), and doesn't require passing any extra data along with the event object (which I try to avoid, as it makes things unpredictably complex). It also lets me return a useful and obvious value from the add member function (the collection key, the final member object, etc), which would be more difficult if there were a layer of indirection between the actual adding code and the function the user calls when they wish to add to the collection.

The second option, while more complex, allows for a lot more granularity of behavior. I could attach event listeners to "beforeAdd" and intercept and modify incoming members to the collection. I could call ev.preventDefault to prevent adding entirely. Going this direction could potentially allow me to reuse the same class type in more contexts instead of having to subclass (or apply a mixin) to get the additional functionality I want.

I couldn't find a clear precedent in the YUI 3.1 source code, so I'm tossing it out here for discussion.

I vote for the second option. As a user, I want to be able to listen for the add event and determine from the payload if I should stop the event or let it go. If I stop the event, the add never happens..

+1 for option 2.

That is indeed the direction I went. The add function now tosses off an event that can be prevented. There are a few minor details I'm not too pleased with that are related to some other implementation details, but being able to intercept an add or remove will be extremely useful.

Once the code is in a less embarrassing state, I'll toss it up on github.

A minor update, after rewriting the library a couple times, I'm now happy enough with how it's structured to put it up on github:

Collection.js

The code is undocumented right now, but the usage is fairly straightforward. There are references to a primitives library in that same git repo that act as (right now, anyway) very rudimentary wrappers for three non-dereferenced value types in Javascript (Boolean, String, Number).

There are some improvements I can make, but this is a stepping stone to bigger and more interesting problems.

Nick Husher