> -----Original Message----- > From: Mark S. Miller [mailto:[EMAIL PROTECTED] > Sent: 20. mars 2008 17:29 > To: Lars Hansen > Cc: [email protected] > Subject: Re: ES4 draft: Name > > 2008/3/20 Lars Hansen <[EMAIL PROTECTED]>: > > 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. --lars _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
