Close review of Language Overview whitepaper
liorean at gmail.com
Thu Nov 15 18:19:51 PST 2007
On 14/11/2007, Maciej Stachowiak <mjs at apple.com> wrote:
> Section III.
> Syntax: The new non-contextual keywords, and the resulting need to
> specify dialect out of band, are a problem. I'll have more to say
> about compatibility under separate cover.
The model with version and e4x arguments in the Content-Type for
changing JS parsing has been used by moz already. Can we hear their
experience with regard to this compatibility problem?
Generally I think opt-in versioning such as this is the best you can
get for compatibility. Perhaps it would be wise to have a method that
is not external to the script as well, though, but I fail to see how
that could work compatibly in current ES3 only implementations.
> - The RegExp change - is this really a bug fix? It's likely that this
> is not a big compatibility issue (Safari's ES3 implementation had
> things the proposed ES4 way for some time) but I think ES3's approach
> may be more performance and generating a new object every time does
> not seem especially helpful.
It's a SpiderMonkey+ES3 fix, as I recall. The main problem with the
ES3 spec is that developers don't expect lastIndex to persist when
they evaluate the literal a second time, but also other mutable
properties. Real world code breaks because of this.
> Is there any significant implementation that anyone would claim is
> 100% free of ECMAScript 3 compliance bugs?
I don't even think you would get 100% compliance if you counted all
engines taken together - I think there's issues where no engine really
"gets it right", or for that matter can afford to "get it right". At
least, no browser hosted engine.
> Section IV.
> Classes: If any of the new type system is worthwhile, surely this is.
> The impedance mismatch between the class model used by most OO
> languages and by specifications like the DOM, and ES3's prototype
> model, is needlessly confusing to authors. So I approve of adding
> classes in a reasonable and tasteful way.
For compatibility reasons with the ES3 bindings for the DOM, I think
the train has already left with regards crafting the DOM bindings
fully into the ES4 model. The way the ES bindings work is incompatible
with both ES3 prototype object hierarchies and ES4 classes/interfaces.
In particular we have multiple parallel interfaces, each of which
developers expect to be an object inherited from using the prototype
scheme. The bindings are incompatible with regards to ES4 interfaces
and classes in that ES4 interfaces from what I understand don't carry
implementation, aren't runtime objects nor can they present prototype
objects (obviously, since they aren't runtime objects).
I can only see two ways to solve this problem:
- Add a multiple inheritance scheme to ES4 that works on the prototype
delegation system as well as the nominal type system, solving the
diamond problem*. --> Severely complicating the object system.
- Remove these multiple parallel interfaces being exposed as run time
objects from the ES bindings, allowing a single inheritance hierarchy
to be formed from implementing them using ES4 interfaces. --> Making a
conformant DOM.next implementation not be a conformant DOM.current
* A good resolution mechanism solving the diamond problem can be found
in Python and was borrowed by Perl 6, IIRC.
> - I am surprised to see a decimal type (a type that is not directly
> supported in current mainstream hardware) even though generally
> popular types like single-precision IEEE floating point and 64 bit
> integers are not present.
I guess it directly addresses one large real world problem - that
fifths are inexactly represented in doubles, and there is a large
demand for reliable number handling of decimal values for amongst
other things money and measurements. I doubt the demand for single
floats or 64-bit integers is even close to as large as the demand for
accurate handling of common real world values like money.
> Section V.
> Record and array types: Structural types are confusingly similar to
> yet different from classes. Mostly they offer a subset of class
> functionality (though reading ahead I did see a few features limited
> to them).
They do allow for orthogonal type ideas, and I think many ES3
developers will be more comfortable with structural types than with
classes and interfaces, because they can add contracts without
changing their coding style. Replacing code written for the ES3 system
of using closures for privacy and prototypes for inheritance with code
written for the ES4 classical inheritance system will require
considerably more rethinking one's implementation.
> Also, already having prototype-based objects and class-based
> objects it seems excessive to add yet a third way. I recommend
> removing them and adding any features that are sorely missed as a
> result to classes.
Well, structural types doesn't really affect the object types, do
they? AIUI structural types are part of the contract system, not the
inheritance model. The object is still just a plain object, it just
has the given constraints.
> Type definitions: Seeing the example of a type definition for a record
> makes this feature seem even more redundant with classes.
> Data Types: If structural types cannot be recursive, then one of the
> canonical applications of record-like types, the linked list, cannot
> be implemented this way. I assume it can be with classes. Yet another
> reason to fold any interesting record features into classes.
Again, the difference is one of contract versus implementation.
Structural types cannot provide implementation, they can only provide
> Nullability: Are non-nullable types really worth it? I am not sure.
> Does any other explicit type system for a dynamic OO language have
> such a concept? The whitepaper says that "the ability to store null is
> occasionally the source of run-time errors" but will not dynamic-
> checking result in runtime errors anyway when assigning null to a non-
> nullable variable (except in strict mode)?
It's a very desired distinction for at least library writers. Getting
early detection of this is very good for both code correctness and due
to possible performance improvements if the engine optimises it.
> Section VII.
> Type annotations and type checking: This section implies that type
> annotations are not at all being added for performance reasons and may
> indeed be harmful to performance. Wow! Seriously? I think runtime
> assertions are interesting when debugging but I do would not want them
> happening for every assignment statement in a release build of my C++
> code. I am not sure why ECMAScript programmers would want that. Later
> this section says "it is plausible" that typed programs will run
> faster and not slower with enough analysis, but this issue seems far
> too crucial to take such a blase attitude. Unless we can show that
> type annotations won't cause a performance hit in practice, and in
> particular give a convincing argument that the relevant analysis can
> be done with reasonable speed and without introducing an ahead-of-time
> compile phase, then it is irresponsible to include type annotations as
> currently designed. I am willing to believe that this is the case, but
> I cannot sign on to an attitude that we don't care if typed programs
> get faster or slower. Nor am I willing to take experience based on
> ahead-of-time compilers as definitive.
Most of the benefit from type annotations and type checking can be
gotten through a good enough compiler even for ES3 code, so I think
the performance side of the issue, while still important, is not at
all as important as being able to put guarantees for correctness.
> Section IX.
> Expression closures: I actually find the examples hard to follow given
> my expectation of ES3-like syntax. I think this may actually be
> syntactic salt.
Mostly it's a question of the code being perceived as slightly off if
you're used to the ES3 function expression syntax only. I still think
the syntax is a bit heavy, but it's pretty neat to have if you're from
> Destructuring assignment and binding: I grudgingly accept that this
> sort of construct has been proven in the context of Python and Perl.
It's sugar and honey to me:)
> Slicing: This one I mildly object to. Array/String slicing is not, to
> my knowledge, particularly common in ECMAScript code of today. I am
> dubious that it merits its own operator syntax.
Seems like an innocent enough extension to me, and for some of the
uses, it should definitely allow engine to perform it faster than if
the developers had to code the equivalent functionality using only
David "liorean" Andersson
More information about the Es4-discuss