|
If you come at this (like I first did) thinking of Packages as
containers, things can get confusing. The secret to understanding is to start with namespaces, which are central and critical to ES4 and backwards compatibility. I won't try to describe namespaces here and will leave that to others far more competent than me, but given namespaces, then packages are really just a syntax shortcut for namespaces. Now you could (as we did), overload the package name as the file name of compiled program elements. However, this has restrictions and complications. It starts burdening package names with meaning you really don't want. Imports directives then become program unit dependencies also. Unit directives provide an independent naming for how various components of a program will be bundled. Often these do not lie along package or namespace boundaries. Units also provide dependency information. We use units directives to group program elements and name them as external (pre-compiled) byte code files. In our case, we use the UnitName as the name of the byte code file. We currently don't use the unit URL. The compiler also has the option to merge all units and dependent units into a single output file. Each unit file can thus have code from one or more packages. Determining the units for an application thus become a loading and network consideration. So the unit proposal gives flexibility in deciding what program elements should be loaded or transmitted as a unit. This is often independent of and at cross purposes to package or namespace naming. Michael Our compiler uses the UnitName of the unit directive to name compiled byte code files. Brendan Eich wrote:
|
_______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
