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/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
