Class method addition and replacement (was Re: AOP Compatibility)
brendan at mozilla.org
Sun Apr 6 13:07:23 PDT 2008
On Apr 6, 2008, at 3:06 AM, Nathan de Vries wrote:
> I'm not denying that the problems you're trying to fix aren't
> problems, it's just that I believe a wholesale locking down of the
> language will be too drastic and may result in a shift away from the
You're doing it again: "wholesale locking down" is false as a general
statement, and almost entirely false broken down into particulars.
Are we "locking down" objects created by operator new applied to a
function, or to the built-in Object, Array, String, Number, Boolean,
Date, RegExp, and *Error constructors? No.
Are we "locking down" objects created by initialisers? No (but we are
using the original values of the Object and Array bindings, even in
ES3 implementations today including Firefox 3, to preserve integrity
for defense in depth, against JSON hijacking attacks).
Are we "locking down" classes, new in ES4, so that their prototypes
cannot be extended? No.
Are we "locking down" classes so that their prototype-declared
methods can't be overridden? No.
Are we "locking down" classes against instance extension via ad-hoc
property assignment? Yes, unless you use the 'dynamic' modifier in
front of 'class'.
Is this one last "Yes" therefore "wholesale"? Obviously not.
Since you grant use-cases for sealing objects against mutation, are
you simply arguing about what the default should be (that 'dynamic
class' should not be required to get an extensible-instance factory,
that 'class' should do that)?
> Do you get the feeling that the majority of developers who aren't
> language that doesn't fit their development profile?
No, because as noted above and copiously documented, ES4 is a
superset of ES3. I expect "JS hackers" to continue doing what they
have been doing, with newcomers choosing from a larger toolbelt and
set of styles. We're opening up pathways for evolution that are
either closed or clogged by high-cost barriers in ES3.
> Do you think
> to those who are used to a more traditional approach?
Which tradition do you mean? There are several.
That most Ajax libraries reinvent classical OOP, sometimes with bugs
and always with inefficiencies in code size, runtime, and memory use,
and with integrity holes, suggests that common traditional approaches
could be improved. This we are proposing to do in ES4.
> My gut feeling to those two questions are "yes" and "no", but
> unfortunately that's all it is; a gut feeling.
I think assertions about "wholesale locking down" reflect feeling
trumping analysis. I hope the Q&A above helps you see that
"wholesale" is false.
If we should argue about the default extensibility of instances
created by unmodified class definitions, let's do that. If this is
about other syntax choices, we can argue about those too, but with
specifics, not vague generalities or angst.
If anyone thinks the missing integrity property support (readonly,
don't-delete, inextensible, not shadowable/overrideable, etc.) can be
dispensed with, I've yet to hear a coherent claim to that effect.
Adding minimal metaprogramming functions to mutate existing ES3
structures to enforce some of these properties is not enough, unless
you take the performance hit, close the "in the middle of
construction" integrity holes, and sugar it all with a code generator
or macro system (we have code generators, but they cost enough that
people avoid them and code to the JS metal; we don't have macros yet).
Classes are an integrity device, for programming in the large as much
as for defense against malicious code. There are other such measures
in ES4, e.g. types, fixtures, and const. These fill gaps in ES3 that
can't be faked.
It seems to me the way forward is to make specific arguments about
these proposals, not generalize inaccurately about their being
"wholesale" in effect (they aren't), or untraditional (to the extent
that JS authors today try to fake it, they are not).
More information about the Es4-discuss