Comments below:
> 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 began and have a fairly complete TY_VAL and TY_PROP. Next we did
TY_NOMINAL
and TY_REFLECT. We are missing DEF, STRUCT, NULL, PARAM and LIKE. We
have partial
STRICT.
> 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.
>
I think this is very much an all or nothing. It is hard to separate out
these from each other.
We started with NS_DEF, NS_VAL and NS_PROP. NS_USE was easy
NS_USE is pretty easy once you have NS_VAL and NS_PROP. NS_PKG is
essential if you
are going to handle package qualified variables and avoid name
collisions. So I'd imagine it
would be hard to have a cohesive whole without doing all these items.
> 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.
>
Agree. We had fixtures first and retrofitted namespace (which I would
not recommend). Namespaces
are so foundational, you need to design them in at the start. Otherwise,
there is a lot of rework.
> 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).
>
Looking at the builtins, I can't imagine how you could do them without
namespaces. They
are a vital solution to various name lookup and collision problems.
> 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.
>
There are a whole raft of implementation "toughies" that will vary a bit
from implementation to
implementation. We have spent a lot of time trying to get ES4 to be
small and fast. But there is
a long, long way to go.
Michael
> -Graydon
>
> _______________________________________________
> Es4-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es4-discuss
>
>
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
