Syntax for non-writability and non-configurability

# Raul-Sebastian Mihăilă (7 years ago)

I'd like to propose the following syntax:

const obj = {
  x:| 3, // non-writable property with value 3
  y:] 4, // non-configurable property with value 4
  z:} 5 // non-writable non-configurable property with value 5
};

Perhaps class fields could also use this syntax. Maybe decorators can take care of this but should you really need to use a decorator for something so basic?

# kai zhu (7 years ago)

-1 as far as i'm concerned, const is a wart with surprising behavior that should have never been introduced. best leave the wart as is rather than add more surprises.

# T.J. Crowder (7 years ago)

On Sat, Jul 8, 2017 at 12:31 PM, kai zhu <kaizhu256 at gmail.com> wrote:

-1 as far as i'm concerned, const is a wart with surprising behavior that should have never been introduced. best leave the wart as is rather than add more surprises.

I suggest re-reading more thoroughly. The const has nothing to do with the suggestion, it could just as easily have been a let. The suggestion is about providing a means via syntax in an object initializer to do what can be done now with Object.defineProperty/Object.defineProperties (defining properties as non-writable and/or non-configurable). It has nothing to do with whether the binding the object reference is written to (if it's even written to one) is a constant or variable.

-- T.J. Crowder

# T.J. Crowder (7 years ago)

On Sat, Jul 8, 2017 at 8:09 AM, Raul-Sebastian Mihăilă < raul.mihaila at gmail.com> wrote:

I'd like to propose the following syntax:

const obj = {
  x:| 3, // non-writable property with value 3
  y:] 4, // non-configurable property with value 4
  z:} 5 // non-writable non-configurable property with value 5
};

Perhaps class fields could also use this syntax. Maybe decorators can take care of this but should you really need to use a decorator for something so basic?

Can't say I'm keen on using obscure symbols for this. I would be interested in either standard decorators for it, or another way of doing it in an object initializer, though. Object.defineProperty / Object.defineProperties is really verbose.

-- T.J. Crowder

# kdex (7 years ago)

What about non-enumerability?

If we had a new token for each combination of { non-writable, non-configurable, non-enumerable }, there would have to be seven new tokens. I'm sure I'm not the only one who'd expect some confusion.

Yes, keeping things brief is nice, but I'm not seeing a clear advantage compared to what you would do with decorators:

const obj = {
	@nonWritable
	x: 3,
	@nonConfigurable
	y: 4,
	@nonWritable
	@nonConfigurable
	z: 5
};

If this is simply about brevity, just alias them to something the next intern would be afraid of:

const obj = {
	@w
	x: 3,
	@c
	y: 4,
	@w
	@c
	z: 5
};
# kai zhu (7 years ago)

legitimate Object.defineProperties use-case is low and obscure enough it can stay verbose. most of the time it causes more code-maintainability issues / tech-debt than it solves.

# T.J. Crowder (7 years ago)

On Sat, Jul 8, 2017 at 1:36 PM, kai zhu <kaizhu256 at gmail.com> wrote:

legitimate Object.defineProperties use-case is low and obscure enough it can stay verbose. most of the time it causes more code-maintainability issues / tech-debt than it solves.

Can't agree with that opinion. But we can easily agree on not adding obscure symbols for it.

-- T.J. Crowder

# Allen Wirfs-Brock (7 years ago)

Note that something similar was given serious consideration by TC39 for ES6 but was ultimately being rejected: harmony:concise_object_literal_extensions, harmony:concise_object_literal_extensions

You can probably find relevant discussions in the es-discuss archive and TC39 notes.

# J Decker (7 years ago)

esdiscuss.org/topic/wiki-ecmascript-org

wiki.ecmascript.org hasn't been up for 2 years? when I ping it I get no address (v4 or v6)

# Allen Wirfs-Brock (7 years ago)