Namespaces as Sugar (was: complexity tax)

[ihab.awad at gmail.com]

Delurk to ask a question --

On Tue, May 27, 2008 at 12:18 PM, Mike Shaver <mike.shaver at gmail.com> wrote:
> In a browser, "window" is the global object; would property lookup on
> "window" be namespaced when referenced as such?  When you have a
> handle to another window?  When you use |this.prop| in a global
> function?

What is wrong with the following strawman syntax: Define a form --

  import into <target> values <namespace>;

which puts all the values <namespace>.* into <target>. This can be
explained in terms of two first class objects, <target> and
<namespace>. Now the global case is just a matter of defining an alias
for the global <target>, in case it is not mentionable by a given JS
environment. Like maybe --

  import values <namespace>;

The remainder of the asymmetry, where the global lexical scope is
addressable as an object yet nested scopes are not mentionable as
first-class objects, is endemic to JavaScript and perhaps not a valid
topic of debate or change at this point.

This seems to solve the problem for module linkage, yet does not
introduce complexities in general purpose object key lookup. It can be
modeled simply as an addition of (possibly "virtual") keys to an
object. And it (correctly) requires the client to have write access to
the <target>.

The problem occurs if you wish to fail "late" in case two namespaces
define the same name. This is where the keys can be virtualized so
that, at lookup time, an error occurs if a name is ambiguous. Yet this
is still localized to one first-class object resolving string keys to
first-class object values, which is well within the simple programmer
model of existing JS.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA