Jeff Dyer wrote:
> The basic workflow:
>
> Proposal -->
> Implementation -->
> Feature spec -->
> Feature review -->
> ES4-RI -->
> ES4 spec -->
>
One thing that springs to mind when looking at this is that the
proposals -- that is, really, the "features" to be implemented -- have
implementation dependencies that need to be reflected in any work plan.
I pointed this out in the phone meeting today and was asked to outline
some of the implementation dependencies I've noted while working on the RI.
I think a certain number of features are mostly-independent of all
others, so they can be cleared off first: enhancements to unicode and
regexps, slice syntax, string.prototype.trim, the global object, triple
quotes, line terminator normalization, improvements to Date, the set of
"pure bug fixes" in ES3, expression closures, let-binding, fixes to the
arguments object, control of enumerability, destructuring assignment.
These are all essentially stand-alone and several have already shipped
as vendor extensions to ES3.
Going further, I have mentally considered the language as providing 3
"big" categories of enhancement: fixtures, types, and namespaces. I
think that within -- and possibly between -- these groups there are
dependencies. For example, we can consider these "levels" of
type-implementation:
TY-VAL: a runtime representation of types exists, and values have
a pointer to their type
TY-PROP: properties can be annotated with types, and a dynamic
check is made when an assignment is made
TY-DEF: type-aliases ("type T = ...") can be defined
TY-STRUCT: the full structural type grammar exists (object types,
array types, function types)
TY-NULL: the nullability extension to the type grammar exists
TY-NOMINAL: class and interface types exist, with a hard-coded
subtype lattice
TY-PARAM: the parametric type system exists
TY-LIKE: the 'like' types exist
TY-STRICT: approximate static checking of types
TY-REFLECT: meta-objects exist and can be acquired with typeof
This is a partial dependency list. You need at least TY-VAL to do
TY-PROP, but it's probably possible to implement any combination of the
remainder once you're at TY-PROP. You could also stop *at* TY-PROP, only
permitting users to denote the ES3 types (prims and objs). Though IMO
this would be silly.
We can also consider "levels" of namespace-implementation:
NS-VAL: a runtime type "namespace" exists, and has some nonempty
population
NS-PROP: every property has a namespace and namespace references
can be used in reference expressions like obj.ns::prop
and ns::lexref
NS-USE: the "use namespace" and "use default namespace" pragmas
automatically qualify definitions or references
NS-DEF: "namespace" declarations are accepted and new namespaces can
be defined through them, either anonymous or with strings
NS-CLS: classes (and interfaces?) define their own namespaces for
conventional OO visibility control
NS-PKG: the "package" construct exists for automatically defining
namespaces
Similarly, this list is more linear at the top than the bottom: NS-PROP
and NS-USE require NS-VAL, though one could stop there with (perhaps) a
fixed population of namespaces. The remaining 3 are mostly orthogonal:
you could for example stop implementing with NS-DEF and ignore classes
and packages, and still have a useful system. Or do NS-CLS alone and
ignore NS-DEF, using namespaces only to model class-visibility issues.
All the type and namespace issues depend, however, on fixtures. We are
some ways towards "proving" that fixtures-in-absence-of-namespaces are
equivalent to the "dontdelete" property attribute (see ticket #233,
http://bugs.ecmascript.org/ticket/233) but if you have namespaces there
appears to be a requirement to be modeling fixtures, to run the
multiname algorithm properly. Fixtures are sort of "super-dontdelete"
properties -- those that can safely be early bound, in addition to not
being deletable -- and it's hard to make much use of the namespace or
type systems without them.
Re-encoding the ES3 primitives as classes, and the new classes like map,
vector and the meta objects, all require a fair amount of the TY and NS
work: at least TY-NOMINAL, TY-PARAM and NS-CLS (I think).
Finally there is a category I left off the above elaboration, mostly
because it is under-developed in the RI: control mechanisms. There are
dependencies between tail calls, generators and stack inspection, and I
can't say I fully understand the dependencies nor the impact they have
on the rest of the implementation.
-Graydon
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
