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