Syntax for non-writability and non-configurability
-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.
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
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
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
};
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.
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
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.
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)
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?
I'd like to propose the following syntax: ```js 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170708/11149b1f/attachment.html>