ES4 draft: Name

Mark S. Miller erights at
Thu Mar 20 17:29:22 PDT 2008

2008/3/20 Lars Hansen <lhansen at>:
> Last call for comments.

Since you're asking for a last call, I'll go on record as objecting to
the introduction of Names, Namespaces, packages, and units. I think
the current JavaScript practice --- of using lexical scoping, objects
as records, package naming paths as dotted paths through records
(e.g., Dojo & YUI) --- addresses most of these needs by patterns
expressed using more basic primitives. If these new concepts were
merely conveniences that could be explained as supporting and
abstracting such patterns, as various Scheme module systems have done,
that would be much less of a problem. (Even then, such adventures
should not be designed in a standards committee.) However, as proposed
as new *primitive* concepts, these don't pull their weight. I also
object to classes on similar grounds, but we should probably keep that
discussion separate.

The one use-case I can see for names and namespaces that isn't
addressed adequately by existing patterns is expanding the
property-name-space, to avoid accidental collisions on extensions to
common abstractions. I note that Smalltalk has long faced this issue,
and I know of at least three independent proposals for first-class
selector names that were intended to address it. At least one of these
were actually implemented. None were ever adopted by a significant
user community. The problem with all of these is that, by introducing
another layer of translation between the identifier the programmer
wrote and the thing that's looked up, you have to introduce and
explain all the mechanism for determining which translation to use in
what context. (The T variant of Scheme is the only example I know
where first-class selectors saw significant use. Though widely
admired, no other Scheme or Lisp variants picked up on this feature.)

As I understand the history, proposed ES4 Names and Namespaces came
from XML namespaces by way of the e4x adventure. However, there's a
big difference. XML fully qualified names are founded in string
identity (by comparing URLs). Their semantics can be explained by
expansion to mangled strings as names ("<url>:local-name"). Proposed
ES4 Names and Namespaces are founded in object identity. I don't like
XML-style names either. But mangled-strings-as-names don't present any
novel serialization problem beyond those of simple-strings-as-names.


More information about the Es4-discuss mailing list