ES4 draft: Name

Lars Hansen lhansen at
Thu Mar 20 20:07:04 PDT 2008

> -----Original Message-----
> From: Mark S. Miller [mailto:erights at] 
> Sent: 20. mars 2008 17:29
> To: Lars Hansen
> Cc: es4-discuss at
> Subject: Re: ES4 draft: Name
> 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.

I should note a couple of things about the proposed language.

Program units will disappear from the language, this has been
clear for a while.  They don't pull their weight as a third
modularity concept on top of packages and namespaces.  (Units were
never a modularity concept, they were always a loading concept,
and motivated by optimizing for the web.)

Packages have always been understood as sugar for namespaces but the
desugaring has not been perfect; we're still working on that, and
it's important to succeed in that.  Packages make sense as sugar
because they capture a useful programming pattern (the public/internal
distinction) for larger sections of code than the class, with
minimal fuss.  (Beyond the desugaring issue I also think packages
have weak integrity properties and that we probably should improve
those, but that's a different discussion.  As they are, they're no
worse than packages in this regard.)

Names depend on object identity insofar as some namespace values
are equal only to themselves.  I don't know how serialization is
a problem that figures into this, though clearly some namespaces
values can't be printed and then reconstituted in the language.


More information about the Es4-discuss mailing list