The Closure Builder is perfectly capable of resolving/optimising namespaces, especially when provided with the proper context using the 'goog.require' statements and '@type' annotations. I don't think there is any reason to duplicate this information in a custom solution.
As to 'collisions' with reserved objects, the Closure Compiler is well aware of those: I just create a package 'alert.acme.flex.SomeClass' and tried to feed it through CC and I got: "ERROR - Variable alert first declared in externs.zip//window.js". These 'externs' definitions are part of the Closure Tools, so I think we're safe in this regard. EdB On Fri, Dec 7, 2012 at 1:21 PM, Frank Wienberg <fr...@jangaroo.net> wrote: > On Fri, Dec 7, 2012 at 10:12 AM, Erik de Bruin <e...@ixsoftware.nl> wrote: > >> adobe.classes["com.example.components.MyTextButton"] >> = com.example.components.MyTextButton; >> [#Remove line, obsolete] >> > > I think I can imagine why the original author (Bernd?) added this output. > Using nested JavaScript objects to represent packages is nice, because it > resembles the ActionScript syntax, but has a runtime penalty for nested > packages (serveral property accesses instead of one) which may be hard to > optimize for GCC. Also, it pollutes the global scope, because all top-level > packages (here: "com") are added as properties of the global object. > Imagine someone calls a package "alert.acme.flex"! > Thus, it could be an option to only add packages to a global PACKAGES hash > (which is in turn inside the "apacheflex" namespace or whatever we'll name > the global framework object), and only copy those packages/classes to the > more JavaScript-friendly format which are "exported". -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
