On 14/11/2007, Maciej Stachowiak <[EMAIL PROTECTED]> 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. <somewhat offtopic> 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 implementation. * A good resolution mechanism solving the diamond problem can be found in Python and was borrowed by Perl 6, IIRC. </somewhat offtopic> > Literals: > - 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 constraints. > 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 FP background. > 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 ES3. -- David "liorean" Andersson _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
