brendan at mozilla.org
Wed Mar 26 15:48:02 PDT 2008
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
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.
More information about the Es4-discuss