Discuss
  • Exemplar forms

Exemplar forms

# Axel Rauschmayer (14 years ago)

From: Allen Wirfs-Brock <allen at wirfs-brock.com> Subject: Re: Exemplar forms (was Your search - "|>" - did not match any documents) Date: October 14, 2011 23:19:16 GMT+02:00 To: Jake Verbaten <raynos2 at gmail.com> Cc: Brendan Eich <brendan at mozilla.com>, es-discuss <es-discuss at mozilla.org>

For a oExemplar like this:

var Exmplr = { constructor () {/.../} }

we would want to automatically generate a "prototype" property such that Exmplr.constructor.prototype === Exmplr is true.

If we could find a way to mark methods as constructors (e.g. by prefixing an @, but we are heading into Grawlix territory then), we could do the following:

var Point = {
    @constructor(x, y) {
        this.x = x;
        this.y = y;
    }
    @zero() {
        this.constructor(0, 0);
    }
}
let p1 = new Point(5, 6);
let p2 = new Point.zero();

Not surprisingly, I like oExemplars. They almost look like class literals, too.

I’m a bit skeptical about having two competing exemplars (more than one way of achieving something leads to confusion, in my experience). I would feel better if oExemplars were the preferred one and fExemplars there for legacy compatibility.

# Axel Rauschmayer (14 years ago)

[cc-ing es-discuss]

On Oct 17, 2011, at 11:31 , Jake Verbaten wrote:

If we could find a way to mark methods as constructors (e.g. by prefixing an @, but we are heading into Grawlix territory then), we could do the following:

var Point = {
    @constructor(x, y) {
        this.x = x;
        this.y = y;
    }
    @zero() {
        this.constructor(0, 0);
    }
}
let p1 = new Point(5, 6);
let p2 = new Point.zero();

How is that different from

zero() { return new this(0, 0); }

Works just as well (because JS engines optimize away the unused instance that is created via "new"), but I like the elegance of distinguishing between instantiation and initialization.

Why do we want named constructors?

To better distinguish between several constructors. Does not happen often, but when it happens, it is handy to have.

Example: Array (which will be fixed in a different manner, via Array.of(), so this is just for illustrative purposes):

new Array(2,3,4) is the same as [2,3,4] new Array(2,3) is the same as [2,3] new Array(2) is the same as an empty array of length 2.

With named constructors: new Array(2,3,4) new Array.sized(2)

Not surprisingly, I like oExemplars. They almost look like class literals, too.

I’m a bit skeptical about having two competing exemplars (more than one way of achieving something leads to confusion, in my experience). I would feel better if oExemplars were the preferred one and fExemplars there for legacy compatibility.

I would agree fExemplars should be there for legacy compatibility and that we should encourage oExemplars. If the oExemplars are not the preferred one then we shouldn't be implementing them and should just continue using fExemplars

Right, which aren’t too bad with class literals or one of the class definition patterns.

# Jake Verbaten (14 years ago)

On Mon, Oct 17, 2011 at 11:19 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

[cc-ing es-discuss]

On Oct 17, 2011, at 11:31 , Jake Verbaten wrote:

If we could find a way to mark methods as constructors (e.g. by prefixing

an @, but we are heading into Grawlix territory then), we could do the following:

var Point = {
    @constructor(x, y) {
        this.x = x;
        this.y = y;
    }
    @zero() {
        this.constructor(0, 0);
    }
}
let p1 = new Point(5, 6);
let p2 = new Point.zero();

How is that different from

zero() { return new this(0, 0); }

Works just as well (because JS engines optimize away the unused instance that is created via "new"), but I like the elegance of distinguishing between instantiation and initialization.

Why do we want named constructors?

To better distinguish between several constructors. Does not happen often, but when it happens, it is handy to have.

Example: Array (which will be fixed in a different manner, via Array.of(), so this is just for illustrative purposes):

new Array(2,3,4) is the same as [2,3,4] new Array(2,3) is the same as [2,3] new Array(2) is the same as an empty array of length 2.

With named constructors: new Array(2,3,4) new Array.sized(2)

Not surprisingly, I like oExemplars. They almost look like class literals, too.

I’m a bit skeptical about having two competing exemplars (more than one way of achieving something leads to confusion, in my experience). I would feel better if oExemplars were the preferred one and fExemplars there for legacy compatibility.

I would agree fExemplars should be there for legacy compatibility and that we should encourage oExemplars. If the oExemplars are not the preferred one then we shouldn't be implementing them and should just continue using fExemplars

Right, which aren’t too bad with class literals or one of the class definition patterns.

This might be a good point to mention that class literals desugaring to oExemplars might be nice. I think there's a stronger 1-1 relation between oExemplars and class literals. Doing this would also make oExemplars the preferred use because the new class syntax would encourage them.

# Allen Wirfs-Brock (14 years ago)

On Oct 16, 2011, at 4:05 PM, Axel Rauschmayer wrote:

From: Allen Wirfs-Brock <allen at wirfs-brock.com>

Not surprisingly, I like oExemplars. They almost look like class literals, too.

I’m a bit skeptical about having two competing exemplars (more than one way of achieving something leads to confusion, in my experience). I would feel better if oExemplars were the preferred one and fExemplars there for legacy compatibility.

Yes, but an important point I was trying to make is that we already have two competing forms of exemplars (three, if you include forms using Object.create). Class literals add yet another exemplar form.

# Axel Rauschmayer (14 years ago)

True.