launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-10-27 07:55 PM, Ian Booth wrote:

> 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.

I guess I see it differently.  To me, it's not about design patterns,
it's about whether to add an extra layer.  I think it's not the same
result, because using YUI's oo means there's a whole bunch of extra
YUI code involved.

I just didn't see a strong reason to have an extra layer, and I wanted
to get more experience with JavaScript's native oo.

I'd agree that consistency can be a good reason, but AFAIK, both
styles of oo are used in Launchpad, so either would be inconsistent.
And I also think that any JavaScript programmer ought to be familiar
with JavaScript's native oo.  They'll encounter it sooner or later,
perhaps even when debugging their own YUI-oo objects.

> 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.

I don't think we're an island.  I could easily imagine extracting this
code out to lazr.batchnavigator, and then the YUI requirement would be
an unneeded barrier to entry.

> 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.

I agree, Y.Base doesn't so increase the programming complexity very
much, but a library should *reduce* the programming complexity.  I
find it annoying having to call .get("foo") to access each attribute.
 And I do wonder whether making method calls instead of doing direct
variable access carries a significant performance penalty.  What is
the cost of supporting change events and attribute validators, when
you're not using them?

> 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.

I am sorry I gave you nightmares, but at the time I implemented
IORecorder (now unified with the lazr-js one as MockIo by henninge), I
could not find another implementation.  I believe I implemented
IORecorder essentially in parallel with lazr-js being integrated into
the tree.

> 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.

We use a whole bunch of different kinds of persistent storage, IPC,
serialization, etc in Launchpad.  The main question is whether the
advantages of each justifies the cost of the friction it introduces.

I don't think native JavaScript oo should cause much friction.  Every
JavaScript programmer ought to know it.  And since JavaScript provides
prototype-based oo, it doesn't seem like a great idea to layer
class-based oo on top of it.  The abstraction will leak sooner or
later, and if you don't know prototype-based oo, you won't understand
what's really going on.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6qreIACgkQ0F+nu1YWqI3pFQCfbLmQitK1MQyuKia0RJVSojqu
h4MAn2vS5JDFLN458C/3AhjqiLdWehHo
=O1jH
-----END PGP SIGNATURE-----