[[Set]] vs [[DefineOwnProperty]]

[bakkot]

There's some debate over what the semantics should be. I wanted to try to collect arguments in one place.

Set	Define
= implies Set.	We could use a different sigil (although not :).
People expect to be able to copy code from the constructor to the class body and have it work the same.	We don't currently have a syntax-level Define for classes, and we can or should use new syntax to do new things.
Most JS programmers do not distinguish between imperative and declarative position.	It is a declarative position. In most cases Set and Define will behave identically, and programmers will have to learn which is which in the remaining cases anyway.
If a class defines a setter for foo to maintain some invariant, some people might be surprised that adding an initializer for foo shadows it instead of triggering it. Also, library authors use setters to deprecate properties (by allowing their use but printing a warning), and subclassers will only get those warnings if initializers use Set.	In an object literal, { set foo(x){}, foo: 0 } does not trigger the setter.
	Define will allow us to later introduce const properties or types. (And potentially decorators.)
Babel uses Set.

We also have the option of some hybrid strategy: for example, throwing if an initializer would overwrite another property and/or throwing if an initializer would shadow a property from the prototype.

[bakkot]

Ping @ljharb; do you see any I missed?

[ljharb]

When talking about a base class, your "object literal" example holds. However, when using extends, there's not really an analog to object literals (using __proto__ inline isn't really the same thing at all), so I think it's worth noting that the hazard mentioned on that row doesn't actually come up with object literals.

[bakkot]

Here's another, slightly more complex argument in favor of Define:

Because static methods and static fields are installed as properties of the same object, I would expect them to work very similarly. It would be very surprising if, for example,

class A extends B {
  static set foo(){}
  static foo = function(){};
}

triggered the setter, given that

class A extends B {
  static set foo(){}
  static foo(){}
}

redefines foo.

So (if you buy this argument) static fields ought to be created with DefineOwnProperty, presumably as writable, configurable, and non-enumerable. For consistency, non-static properties should be created the same way.

[ljharb]

Interestingly, Babel here doesn't actually redefine it, although Chrome native does.

[bakkot]

Babel gets class properties wrong in a number of ways - for example.

The spec is unambiguous (see step 21.b.i and here); Babel's just wrong.

[domenic]

I don't find that argument compelling. Consider the following code, which I claim is completely analogous:

var o = {
  set foo() {}
};
o.foo = function () { };

vs.

var o = {
  set foo() {}
  foo() { }
};

It is very unsurprising to me that the first triggers the setter and the second redefines.

[bakkot]

@domenic, I would think the closer analogy would be

var o = {
  set foo(x){},
  foo: function(){}
}

given that the field is inline, not after-the-fact.

[domenic]

Nah, that uses :, not =; you need = to keep the analogy.

[bakkot]

Eh, part of the discussion is over which sigil to use. Without considering the sigil, it seems that static field declarations ought to work the same as static method declarations.

[bakkot]

(Although even with =,

class A {
  static set foo(x){}
  static foo = function(){}
}

is more visually similar to

var o = {
  set foo(x){},
  foo : function(){}
};

than

var o = {
  set foo(x){}
};
o.foo = function(){}

to my eye.)

[RyanCavanaugh]

A subsequent duplicate declaration without an initializer isn't something we have to cook up never-written object literals to think about. JS already has this:

var x = 0;
var x;
console.log(x); // Does not print 'undefined'

The cognitive burden here just seems enormous for no actual upside. How would you explain this feature to a user?

Set

p = e; in the body is just sugar for writing this.p = e; at the top of the constructor

Accurate & is analogous to a thing people actually do today.

Define, v1

p = e; in the body is just sugar for writing Object.defineProperty(this, "p", { value: e }); at the top of the constructor

Sugar for a thing I never do? What is defineProperty exactly? Huh? What's the difference between that and this.p = e; ?

Define, v2

p = e; in the body is just sugar for writing this.p = e; at the top of the constructor unless there's a base class property with a setter in case your class will break for impossible-to-debug reasons that will ultimately lead to your team banning class property initializers because they block ergonomic updates to base class implementations

Is analogous to a thing people actually do today & spells out the consequences of using this feature when you're not in a position to inspect the implementation of the base class.