launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

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