A random collection of ES4 draft spec surprises and thoughts
graydon at mozilla.com
Mon May 26 11:57:26 PDT 2008
Mark S. Miller wrote:
> In going over the ES4 draft spec docs, I found the following things surprising:
I can't answer all of these, but can a few. Most of the grammar
questions are outside of things I know.
> * I thought "like" was dead. How did it get revived?
As a (value * type) binary operator, rather than as a type. It also
(presently) has a form in which it can annotate a function parameter,
which implicitly causes the an assertion of the operator against the
provided type when the function is entered. This annotation behavior on
function parameter lists is something I'm not terribly pleased with, but
then, the most natural boundary between annotated and unannotated code
appears to be that of a function call, so it's possibly sensible to
leave extra conveniences there.
> * What is
> "super" "(" Arguments ")"
> ? Last I heard, ES4 only has single implementation inheritance, so why
> allow "super" to be qualified?
I don't know what you mean by qualified. That's a form for either
constructor-chaining or dispatching to a parent method with the same
name as the current method.
> * I'm pleasantly surprised to see that the prototype reference (which
> I take to be the same as the ES3 internal [[Prototype]] property) is
> said to be immutable. Does this mean that we will be able to consider
> the following behavior buggy (I hope so):
> * What namespace is "__ES4__" defined in? The text "The namespace
> __ES4__is predefined. It is used to tag global names that have been
> introduced in the 4th edition" would seem to indicate that __ES4__ is
> itself defined in the namespace __ES4__. I'm probably missing or
> confused about something.
Sorry about this. There was text in the section on names that clarified
the root namespace bindings but it appears to have been cut during some
rewriting. I'll try to ensure it shows up again.
At the moment the ES4 namespace is visible as the global property
__ES4__ to 3rd edition code, because it is bound to the global name
""::__ES4__ and 3rd edition code has the transparent public namespace ""
open in its root scope. This is the "backwards compatibility hazard" if
some 3rd edition code happens to accidentally wish to reuse the global
All other names introduced are qualified by the ES4 namespace, or by
namespaces that are themselves qualified by the ES4 namespace (including
things like the "public" synonym for the transparent public namespace;
that's actually bound to __ES4__::public). So 3rd edition code is not
going to collide with such names, since 3rd edition code is never going
to contain a name expression __ES4__::foo that would be necessary to
start digging around in that namespace.
The ES4 namespace is open in the root scope of any 4th edition code.
You're right that we could possibly get away with only binding the ES4
namespace to, essentially, <ES4>::__ES4__, where <ES4> is the opaque
namespace object itself. We don't do that at present, but we've tried to
keep any name pollution to a minimum so this might be a desirable final
touch if we can make it work.
> * Unicode only has 21 bits of significance. That's enough headroom
> that we should expect Unicode to live within these limits until the
> United Federation of Planets makes peace with the Romulans and the
> Klingons. So why is a string value defined as "a finite ordered
> sequence of zero or more 32 bit unsigned integer values"?
Because a string value in the 3rd edition is defined as "a finite
ordered sequence of zero or more 16 bit unsigned integer values".
Emphatically *not* as a unicode string. Unicode strings are a useful
subset of what a 3rd edition string value can hold, but they're not
defined that way. In particular, the private surrogate range is totally
fair game in 3rd edition implementations. The expansion to 32 bits is
simply a matter of utility: it's much more useful in general to have a
dense u32 sequence than a dense u21 sequence.
> * What does "Rib" mean? Is it an acronym?
Not an acronym. A rib is a (name -> fixture) binding map. It defines the
set of fixed properties that will exist in a scope or an instance.
There is some redundancy between ribs and non-value property states, in
the present RI. I'm in the process of eliminating this redundancy in
favour of relying on ribs directly, and using properties only to model
what's now called the value state.
More information about the Es4-discuss