Hello
My view is that I would rather adopt a consistent approach to these
sorts of things, rather than using various design patterns to achieve
the same end result. The argument about someone without YUI experience
looking at the code I don't think is relevant because YUI is our
framework of choice and the entire codebase relies on it, so I can't see
someone not knowing YUI being able to make much sense of too much at all
really. In fact, I would much rather learn YUI or whatever the framework
is than look at several different implementations of something and try
to figure out the "correct" or acceptable one to use. Using Y.Base
doesn't really add much to the programming complexity and as stated
below, offers a seamless path to using change events and attribute
validators when required.
As a concrete example of the consistency issue, we had/have several
different mockio implementations and it was/is a nightmare trying to
figure out which one to use. So say lp.code.javascript used one
implementation and lp.bugs.javascript used another and (the former)
lazr-js yet another, one was forced to decide between staying consistent
with what was there already in each code base or using what one knew
from prior usage etc. This sort of thing kills developer velocity. Much
easier just to standardise on one implementation and extend that as
required if it didn't do some particular thing.
That's my 2c.
On 28/10/11 04:22, Deryck Hodge wrote:
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
_______________________________________________
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
