Prototypes as the new class declaration

Peter Michaux petermichaux at
Sat Jun 18 10:00:58 PDT 2011

On Tue, Jun 14, 2011 at 10:08 PM, Allen Wirfs-Brock
<allen at> wrote:

> The correspondence is even closer if we slightly extend the new operator.
>  Using current new operator semantics and my alternative way of defining
> SkinnedMeesh and then executing:
>   let aSM = new SkinnedMesh(aGeo, aMat);
> we would get a TypeError because SkinnedMesh does not have a [[Construct]]
> internal method.  However, it would be a small extension to the new operator
> for it to invoke its operand's constructor method if the operand is an
> object that is not a function (alternative, we could give every object
> created using an object literal a [[Construct]] internal method that invokes
> the constructor method, its really just an alternative way to specify the
> same thing.

Interesting extension of "new".

> BTW, I believe that somebody else recently on one of these
> threads also suggested allowing the new operator to be applied to any object
> so feel free to take credit.

Don't need credit but perhaps you were referring to my email...

On Wed, Jun 15, 2011 at 8:20 PM, Allen Wirfs-Brock
<allen at> wrote:

> Alternatively, if there was a more complex set of methods or there was an a
> strong reason why you didn't want instances to share the behavior. You would
> create a separate singleton helper/factory object to hold the methods, EG,
>    StringBulider.fromCharCode(1,2,3,4,5)
>    StringBuilder.fromStrings("abc","def","xyz")
> Of course, such an object could participate in its own inheritance hierarchy
> that was decoupled from Strings, EG,
>    let I18NStringBuilder = StringBuilder <|
> {fromLocaleString(template,locate) {...}};

It would be nice to see constructors heading in this direction of
being methods on objects that can inherit.

> These examples seem to suggest that there are plenty of reasonable ways to
> approach what currently would be constructor methods.  However, they all
> require some rethinking that starts with the concept that you name the
> prototype and not the constructor.  The biggest hurdle to me  seems to be
> that the existing built in objects don't follow that pattern.

and host objects?

On Sat, Jun 18, 2011 at 8:09 AM, Brendan Eich <brendan at> wrote:

> For me, this does not close the deal that we don't need classes.
> But it is getting close, and it is working in the right direction.

Do I smell a strawman?

> but I think we all (Harmony types
> at least) want to minimize additions to the language and prefer
> orthogonal primitives that have good usability, and
> which compose cleanly.



More information about the es-discuss mailing list