launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #09630
Re: js timeout issues on ec2 due to deep js namespaces
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12-09-18 01:51 PM, Richard Harding wrote:
> We also should share namespaces among files better. So we're going
> to push for a standard of:
>
> Y.$app.$namespace. For instance, my code in question added a bunch
> of JS for the product. So I created Y.registry.views.NewProduct.
> Other modules and files can share that same namespace
> Y.registry.views and add on other classes such as ViewProduct,
> EditProduct, etc. They can all be in their own files and modules,
> but share the same namespace cleanly and prevent us from layering
> too deep.
I think that we should not do this. You're suggesting breaking the
connection between modules and namespaces, which will make life
harder-- knowing the namespace, we don't know what module is needed.
Knowing the module name, we can guess at the namespace, but we won't
necessarily be right.
You brought up 'array-extras' as an example on IRC, but I think this
is a great example of why we shouldn't. 'array-extras' monkey-patches
the Y.Array class on load. So if your code depends on a Y.Array
method, you don't know what modules you need to load in order for your
code to work.
lp.app.information_type didn't require 'array-extras', but it used
Y.forEach, which is defined in 'array-extras'. Because of this, I had
no idea why the code didn't work. Had forEach been in a
'Y.array_extras' namespace instead, I would have save hours of time,
both mine and yours when I ultimately came to you for help.
Using consistent module and namespace makes coding and debugging
simpler. I don't think we should give that up. If we have to make
our namespaces shorter, we should adjust our modules to match.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBZ1lcACgkQ0F+nu1YWqI14TACfbrVM6lOcbtgWW5xqExxHt7/K
AJIAnAhdB2niEH12F8jUWuVBvq1vXv7N
=CgqR
-----END PGP SIGNATURE-----
References