← Back to team overview

launchpad-dev team mailing list archive

Re: js timeout issues on ec2 due to deep js namespaces


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.

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/