Namespaces as Sugar (was: complexity tax)
brendan at mozilla.org
Mon May 26 10:22:18 PDT 2008
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:
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:
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?
More information about the Es4-discuss