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