Classes as Sugar -- old threads revisited

Mark Miller erights at
Tue May 26 18:44:46 PDT 2009

On Tue, May 26, 2009 at 2:49 PM, Cormac Flanagan <cormac at> wrote:
> Mark,
> Thanks for clarifying this design.
> One important issue to consider is the goal of classes as
> high-integrity, unforgeable objects.
> It seems the desugaring of "class Foo" to "object implements Foo"
> loses this ability ...
>>  class Foo(p1, p2) { ... }
>> desugars to
>>  const Foo(p1, p2) {
>>    return object implements Foo { ... };
>>  }
> since other code can later do:
>    object implements Foo { ... weird behavior here ... }

Yes, as explained:
On Mon, Mar 30, 2009 at 7:41 PM, Mark S. Miller <erights at> wrote:

    The intent of the "implements" clause is that the value
    of the object expression be tagged somehow with an unforgeable nominal
    type, such that this value is able to pass the corresponding
    guard. For now, I will take a shortcut and assume that when a
    guard-value is a function, that the dynamic type-like test is approx

     isFrozenProp(guard, 'prototype') && (specimen instanceof guard)

    If the function's 'prototype' property is frozen, then instanceof is
    at least a monotonic test. However, it is effectively forgeable -- it
    guarantees no useful property -- since anyone may create an object
    that passes this test but has arbitrarily weird behavior. (Thanks to
    Waldemar for emphasizing this point at our last meeting.) In order to
    have a high integrity desugaring of ClassDeclaration or
    ObjectExpression, we need better lower level support for some kind of
    trademarking mechanism. We will need to revisit this issue, but not in
    this note.

> Is there some way to strengthen this behavior?

AFAICT, not using only the mechanisms found in ES5. Yes, given
aforementioned support for some kind of new primitive trademarking
mechanism, as found in Gedanken
<> or W7
<>. Section 6.3 & Figure 6.6 of
<> explain trademarking in E as a step
towards E's auditors <>,
which we may want to consider.

>> which desugars to
>>  const Foo = Object.freeze(function Foo(p1, p2) {
>>    return object implements Foo { ... };
>>  });
> Plus:
>    Object.freeze(Foo.prototype);
> right?

Yes, good catch!

>> As with ConstFunctionDeclaration, if ObjectDeclaration is not accepted
> You mean ObjectExpression, IIUC.

Oops. Yes.



More information about the es-discuss mailing list