Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

On May 26, 2008, at 10:02 AM, Mark S. Miller wrote:

> we could just have these expand into non-identifier
> strings consisting of components (typically identifiers) separated by
> some kind of path separator string. The most logical choices for path
> separator would probably be either "::" or ".".

This is not backward compatible, since code today is free to use such  
substrings in property names, and I will be you a donut real code  
does use arbitrary printable ASCII strings. BTW, this name-mangling  
idea already came up over a year ago:

http://wiki.ecmascript.org/doku.php? 
id=meetings:minutes_apr_18_2007#es_3.1_discussion

Then there is the missing open namespaces idea. Without the ability  
to implicitly qualify identifiers by namespaces, users (as in XML  
with namespaces) have to compose identifiers from different  
namespaces using explicit qualifiers on every reference. This is  
verbose, tedious, and error-prone, and experience from XML suggests  
strongly that it's not sufficiently usable compared to alternatives  
that have a single namespace, or that support unqualified imports:

http://osteele.com/archives/2004/07/a-fresh-canvas
http://osteele.com/archives/2004/08/unqualified-imports-for-xml
http://osteele.com/archives/2004/08/unqualified-imports-for-xml

A single namespace does not scale, we know this from today's  
situation on the web where, by convention, libraries share a top- 
level namespace and put their local names in a single object per  
library (MochiKit, dojo, etc.). This leaves unqualified import as the  
remaining alternative for usability.

In short, reinventing namespaces via name mangling loses backward  
compatibility, and without what Steele calls unqualified import, it  
lacks the usability programmers expect from most other languages with  
namespaces. Users have to cope in exactly this way today using JS1  
(lack of . notation and quote requirements are not the main issue).  
Why not give them both better syntax and better semantics?

/be