namespaces and packages in ES4

[Benjamin Smedberg]

Background: I wrote up a proposal which would make using XPCOM modules (from
script) a lot like importing python packages. See
http://benjamin.smedbergs.us/blog/2006-12-22/simplifying-xpcom-code-patterns/

Brendan mentioned that ES4/JS2 is growing a "package" construct
(http://developer.mozilla.org/es4/spec/chapter_11_packages.html). But I
don't really understand it yet: are "packages" real JS objects that can be
manipulated?

e.g.

package goop {
function DoIt() { return "Done"; }
}

var X = goop
x.DoIt()

Can you use the "import" statement for objects that are not packages? i.e.

var X = {
DoIt: function() { return "Done"; }
}

import X.DoIt
DoIt()

Perhaps I'm being unduly influenced by the python "everything is an object"
mentality, but I don't really understand the compile-time package system
that is being proposed.

--BDS

[Georg Maaß]

Benjamin Smedberg wrote:
> Background: I wrote up a proposal which would make using XPCOM modules (from
> script) a lot like importing python packages. See
> http://benjamin.smedbergs.us/blog/2006-12-22/simplifying-xpcom-code-patterns/
>
> Brendan mentioned that ES4/JS2 is growing a "package" construct
> (http://developer.mozilla.org/es4/spec/chapter_11_packages.html). But I
> don't really understand it yet: are "packages" real JS objects that can be
> manipulated?

The document mentioned by you says NO.

Packages exist only at compile-time. The static existence of packages
allows us to give them certain properties that would not be possible if
they could be manipulated at runtime. In particular,

*
package names may have embedded dots
*
fully qualified package references may and must be expressed
using the dot operator rather than the usual :: syntax for qualified names

But because there is no runtime value for a package name, packages
cannot be aliased or otherwise used in an expression that uses a runtime
value.

When encountered in a valid context by the compiler, the meaning of a
package name becomes fixed; any interpretation at runtime is no longer
possible.

For this reason, a package name always shadows locally defined names,
independent of the scope chain, when that package name is used on the
left hand side of a dot operator.

>
> e.g.
>
> package goop {
> function DoIt() { return "Done"; }
> }
>
> var X = goop

The previous line is nonsence, because there is no goop instance, but
goop is a madatory name prefix for all top-level definitions inside.

> x.DoIt()

You must call DoIt from package goop that way:

goop.DoIt();

> Can you use the "import" statement for objects that are not packages?

No, you do not import objects but declarations.

[Benjamin Smedberg]

Georg Maaß wrote:

> But because there is no runtime value for a package name, packages
> cannot be aliased or otherwise used in an expression that uses a runtime
> value.
>
> When encountered in a valid context by the compiler, the meaning of a
> package name becomes fixed; any interpretation at runtime is no longer
> possible.

[snip]

> No, you do not import objects but declarations.

Is there a document that explains the rationale behind packages/namespaces
as opposed to python-like modules? Many existing JS libraries (and all
python modules) have a design pattern that exposes a single object from
which the entire API is made available (e.g. YAHOO.util from the YUI).

Rather than adding a wholly different compile-time package mechanism, why
doesn't JS2 implement an enhanced version of "module objects"? For ease of
use, individual methods/values from these modules could be imported into the
global scope of a running script. A module declaration could even support
module definitions spread across multiple files:

FILEA.js2:

module BSLib {
function doSomething() { ... }
}

FILEB.js2:

// The object "BSLib" already exists, so this is additive
module BSLib {
function doAnother() { ... }
}

CLIENT.js2:

import BSLib
from BSLib import doSomething

doSomething();

[Georg Maaß]

Benjamin Smedberg wrote:
> Is there a document that explains the rationale behind packages/namespaces
> as opposed to python-like modules?

I did not see a comparison to python there.

> Many existing JS libraries (and all
> python modules) have a design pattern that exposes a single object from
> which the entire API is made available (e.g. YAHOO.util from the YUI).

This mechanism is still available. Packages and namespaces are
additional language features not replacing existing language features.

> Rather than adding a wholly different compile-time package mechanism, why
> doesn't JS2 implement an enhanced version of "module objects"? For ease of
> use, individual methods/values from these modules could be imported into the
> global scope of a running script.

Objects are created at runtime. You may create partial clones if you
like with existing language featues.

You do not import objects from an external environment into your
environment, but you try to solve naming conflicts of libraries from
different sources using packages and namspaces.

So the purpose of this language feature is different than your intension.