launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

Hi, all.

I came across a JavaScript style question when doing a review for
Aaron today that I didn't have a good answer for.  I don't think we
have an explicit policy about this, and I think we should.

Aaron wrote some code where he converted a couple js functions into a
full fledged object.  When he did this, he stayed in raw JavaScript
declaring methods on the constructor's prototype.  (See his MP if you
don't know what I mean by this:
https://code.launchpad.net/~abentley/launchpad/navigate-batches/+merge/80502).

Part of me wanted to ask him to convert this to an object that
extended Y.Base, but I didn't because a) we haven't yet had this as a
requirement and b) he doesn't currently need anything Y.Base provides.
 I see pros and cons either way, and think it would be worthwhile
coming to some consensus about what we prefer here, before asking
someone to so completely rework his/her code.

The upside of Aaron's approach is that it's simpler in terms of
complexity -- he doesn't need anything Y.Base provides, so don't use
it.  It's also pure JavaScript without the YUI trappings, so someone
coming to this code without YUI experience can make sense of it.

The downside is that we don't get any of the stuff YUI provides if we
ever wanted it -- like custom attribute change events and attribute
validators.  Also, if anyone wanted to work with this object outside
the scope of it's current use it won't look or behave like other
Y.Base extended objects.

What do you guys think?  Let the opinions flow please. :)  Should we
require that new objects always extend Y.Base?  Should we let the
author make this choice?  Or something in the middle here?

Cheers,
deryck



-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/