Class method addition and replacement (was Re: AOP Compatibility)

Brendan Eich 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
> language Javascripters have come to know and love.

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
> writing the Javascript you're talking about will be left with a new
> 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
> that the developers who will write large-scale Javascript will cater
> 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).

/be




More information about the Es4-discuss mailing list