On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote: > Let us take action instead of throwing opinions around: > Brendan: What new features that can not be implemented via code > constructs now?
This is reductionism, therefore between silly and wrong, but I will list a few things: * you can't make read-only properties in ES3; *you can't make don't-delete properties of plain old objects (only vars in closures); * you can't make objects that cannot be extended; * you can't make don't-enum properties in plain old objects; * you can't yield from a function to its caller, saving state automatically in local variables, and send a value back to the suspended activation of that function. The last is generators, but let's suppose that we add those. I'm intentionally leaving out things that are hard to do, but can be done, with closures (e.g., guaranteeing that |this| binds to a particular object when a method is called; or guaranteeing that a particular method *will be* called by a given name on an object). Suppose further that you chose the absolute minimal set of additions to support some semblance of a solution for the first four bullets. My response is that adding a few meta-methods to flip property attributes is not thereby "enough", since it is still incredibly verbose, error-prone, inefficient, and subject to "in the middle of construction" integrity attacks to build up "classes" or other ES4 features using objects with const/permanent/non-enumerable additions. Almost no one will write such "classes" out by hand. I noted years ago to Doug (after a talk at Yahoo! I gave) how a macro system would help programmers use some primitives better without adding more surface syntax. He wondered whether we shouldn't do macros first. Problem is macros are not theoretically worked out yet -- and that's in the context of Scheme. So rather than starve the patient further, I argue we should be willing to add syntactic conveniences as well as syntax for new substance. Macros may come, and much can be recast in terms of them, and the ecosystem can take over the business of syntactic extension, to a great extent. Anyway, I don't think my answer here helps decide what to do. Opinions and tastes vary about things like syntax, dynamic meta- programming using fewer primitives vs. declarative new forms that can be (optionally) statically checked, etc. Some people will always prefer to use fewer primitives. It seems better to me to grow JavaScript based on existing "design patterns" used (at some cost) on top of ES3, and based on solutions from "nearby" languages such as Python and ActionScript 3 (to take just two examples). Even this does not mean anything particular about complexity budgets. I will say this: ES4 has overspent its complexity budget in order to explore a large design space. It is now shrinking to meet practical budgets involving Ecma member consensus, prime mover commitments, fatigue effects, community expectations, and the like. No one working on ES4 wants it to be like Perl 6. We aim to finish this year. So you'll see proposals like multimethods getting deferred. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
