Dynamic class default (was Re: Class method addition...)
Mark S. Miller
erights at google.com
Mon Apr 7 14:27:07 PDT 2008
On Mon, Apr 7, 2008 at 10:45 AM, Neil Mix <nmix at pandora.com> wrote:
> On Apr 7, 2008, at 10:37 AM, Steven Johnson wrote:
> > Dynamic classes also incur nontrivial overhead in memory use and
> > runtime
> > performance. IMHO we'd want a fairly compelling argument for making
> > all
> > classes dynamic by default.
> It would probably put an end to the acrimony about ES4 being too
> different from ES3; I'm hesitant to speak for the views of others, but
> I suspect this change would make the language a lot more palatable for
> many currently opposed to it. In that light, "compelling" is going to
> be a highly subjective measurement.
Speaking as one of the more vocal skeptics, this change would make ES4
less palatable for me.
ES3.1 and ES4 are together moving in a good direction by making the
degree of permissiveness controllable on a per-property and per-object
basis. Subjectively, as someone interested in robustness, integrity,
and security, ES3 made a huge mistake in having all these be as
permissive as possible. Both ES3.1 and ES4, in order to be reasonably
compatible with ES3+R, must continue to have the ES3 constructs
default to overly permissive. For ES3.1 the best we can do is provide
explicit operations (such as __defineProperty__) for overriding these
defaults. To my mind, the main virtue of introducing a class syntax to
an ES is an opportunity to get these defaults right this time.
One principle of security engineering is "deny by default is better
than allow by default"; which is closely related to "whitelisting is
better than blacklisting". For ES3.1, we're stuck with
allow-by-default. If the ES4 class syntax were to get this wrong as
well, I'd be even more puzzled about what its purpose is.
Accordingly, my preference is for classes to default to non-dynamic
and non-subclassable. For methods to default to non-overridable and
non-enumerable. And for properties/members to default to non-settable
and non-enumerable. Whatever these defaults are, it's an orthogonal
question whether classes need to be a primitive construct, or whether
they should be just sugar for a less-permissive-by-default usage of
the class-like abstraction pattern of ES3.1.
More information about the Es4-discuss