From: Domenic Denicola d...@domenic.me
To: Rick Waldron waldron.r...@gmail.com, es-discuss es-discuss@mozilla.org
Cc:
Date: Mon, 12 Jan 2015 18:02:17 +
Subject: RE: Implicit coercion of Symbols
I re-read through this whole thread and realized nobody brought up the fact
Indeed, in my first reply on-thread, I wrote
This is exactly the reason.
to acknowledge existing consensus. Thanks for linking!
/be
Domenic Denicola wrote:
I re-read through this whole thread and realized nobody brought up the fact that
this*specific* change, of making `String(symbol)`
Andrea Giammarchi wrote:
A generic description-aware `Reflect.describe(genericObject)`like
approach seems way more useful for logging annd debugging purpose than
a footgun in the wild.
Good idea, should find an ES7 champion. If we had this, I think we could
have made String(sym) throw, and
Le 4 janv. 2015 à 03:18, Rick Waldron waldron.r...@gmail.com a écrit :
On Sat Jan 03 2015 at 8:25:40 PM Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
That example above is pretty compelling for throw always consistency.
With a new Reflect.* API for converting a symbol
Alex Kocharin wrote:
My point is: concatenating Symbols with other strings have
legitimate
uses.
Name one.
I did name one in another message. Logging.
That's a use-case for some way (could be concatenation, but as noted the
downside risk is huge; could be a new Reflect
Alex, like I've said:
`log({__proto__:null})` and welcome crashes of the server, if that's a real
concern in this form.
Is it that wrong to assume that if `console.log({__proto__:null})` is
capable of handling non Objects and print a meaningful output, so should
any other logger implemented on
Claude Pache wrote:
Now, it will be argued that it would be a precedent to make such a distinction
between implicit and explicit coercion, for, until ES5, there is none.
Kind of there all along, as noted up-thread:
js o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function
Forgot to retitle it.
On Jan 3, 2015 9:44 PM, Isiah Meadows impinb...@gmail.com wrote:
From: Axel Rauschmayer a...@rauschma.de
To: bren...@mozilla.org
Cc: es-discuss list es-discuss@mozilla.org
Date: Sun, 4 Jan 2015 03:17:54 +0100
Subject: Re: Implicit coercion of Symbols
Does it have
On Sat Jan 03 2015 at 3:56:38 PM Brendan Eich bren...@mozilla.org wrote:
Axel Rauschmayer wrote:
On 03 Jan 2015, at 19:52, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
None of the objects in the examples bz cited are Arrays -- what did
you mean?
When I though
On 03 Jan 2015, at 19:52, Brendan Eich bren...@mozilla.org wrote:
None of the objects in the examples bz cited are Arrays -- what did you mean?
When I though of `+` being used inside square brackets, I only thought of
strings, not of numbers (first example).
In the first example, `this` is
Arrays are a good point, this is where I’d think accidental coercions are most
likely. The other use case is object-as-dictionary, which will slowly be
replaced by `Object.create(null)` (no need to escape in ES6+) and `Map`.
I don’t feel strongly either way, I just feel that the added spec
Axel Rauschmayer wrote:
On 03 Jan 2015, at 19:52, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
None of the objects in the examples bz cited are Arrays -- what did
you mean?
When I though of `+` being used inside square brackets, I only thought
of strings, not of
Rick Waldron wrote:
Subjectively: I think it's nice in theory, but bad in practice.
Compared to what? Converting a symbol to asilent-but-deadly string?
I thought you were gonna raise the other way to restore consistency:
make String(sym) throw too. Then we'd need a new Reflect op to get a
On Sat Jan 03 2015 at 5:56:33 PM Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
Subjectively: I think it's nice in theory, but bad in practice.
Compared to what? Converting a symbol to asilent-but-deadly string?
Sorry, that was poorly delivered—I was editorializing on the
Agreed with Brendan,
and I've thought the same.
It's been also years we have problems using unknonw objects in the wild,
i.e.
```js
var n = {__proto__:null};
var s = String(n); // error, No default value
var s = '' + n; // error, No default value
```
Same if used as [property accessor] so I
On Sat Jan 03 2015 at 6:30:43 PM Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Agreed with Brendan,
and I've thought the same.
It's been also years we have problems using unknonw objects in the wild,
i.e.
```js
var n = {__proto__:null};
var s = String(n); // error, No default
Rick Waldron wrote:
That example above is pretty compelling for throw always consistency.
With a new Reflect.* API for converting a symbol to its
diagnostic/debugging string?
If you agree, please file a bugs.ecmascript.org ticket.
/be
___
The code will be incorrect if you pass any regular object in there. Why should symbol be any different? For me, its throwing behavior is just another thing that could crash server-side node.js process for no good reason. 04.01.2015, 04:44, "Tab Atkins Jr." jackalm...@gmail.com: On Jan 3, 2015
Alex Kocharin wrote:
The code will be incorrect if you pass any regular object in there.
Why should symbol be any different?
For me, its throwing behavior is just another thing that could crash
server-side node.js process for no good reason.
No good reason? Wrong.
Just because bugs pass
Does it have to be a Reflect.* method? It could be
`Symbol.prototype.getDescription()` or a getter.
On 04 Jan 2015, at 02:25, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
That example above is pretty compelling for throw always consistency.
With a new Reflect.* API for
On Sat Jan 03 2015 at 8:25:40 PM Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
That example above is pretty compelling for throw always consistency.
With a new Reflect.* API for converting a symbol to its
diagnostic/debugging string?
If you agree, please file a
Given that there is currently no way to get a string representation of a value
in a guaranteed side-effect-free fashion, I think something generalized for all
primitive and object types would be ideal.
On Jan 3, 2015, at 9:17 PM, Axel Rauschmayer a...@rauschma.de wrote:
Does it have to be a
04.01.2015, 04:58, "Brendan Eich" bren...@mozilla.org:Alex Kocharin wrote: The code will be incorrect if you pass any regular object in there. Why should symbol be any different? For me, its throwing behavior is just another thing that could crash server-side node.js process for no good
On Sat Jan 03 2015 at 9:41:57 PM Alex Kocharin a...@kocharin.ru wrote:
Also, if you want to prevent mistakes like `object['blah' + symbol]`,
linters could be changed to forbid/warn about concatenation inside property
names.
How would a linter know that `symbol` was actually a Symbol?
Rick
On 1/3/15 9:41 PM, Alex Kocharin wrote:
function log(anything) {
process.stdout.write(new Date().toJSON() + ' - ' + anything + '\n')
}
```
Right now it'll never throw. Well, unless you override `.toString()` to
throw, which I've never seen to be done intentionally.
Just to nitpick, try:
04.01.2015, 05:44, "Rick Waldron" waldron.r...@gmail.com:On Sat Jan 03 2015 at 9:41:57 PM Alex Kocharin a...@kocharin.ru wrote: Also, if you want to prevent mistakes like `object['blah' + symbol]`, linters could be changed to forbid/warn about concatenation inside property names. How would a
Alex Kocharin wrote:
04.01.2015, 05:44, Rick Waldron waldron.r...@gmail.com:
On Sat Jan 03 2015 at 9:41:57 PM Alex Kocharin a...@kocharin.ru
mailto:a...@kocharin.ru wrote:
Also, if you want to prevent mistakes like `object['blah' +
symbol]`, linters could be changed to forbid/warn
04.01.2015, 07:36, "Brendan Eich" bren...@mozilla.org: My point is: concatenating Symbols with other strings have legitimate uses.Name one.I did name one in another message. Logging. If somebody wants to output a variable just to see what it is, something like `console.log('hey, I got this: '
One reason it might make sense to throw, is people converting values to string
names for use as object properties. Reason you'd want to throw would be to
prevent accidentally making the key useless (different from its original Symbol
value).
Haven't paid attention to the rationale, but that
On Fri Jan 02 2015 at 7:53:22 PM Brendan Eich bren...@mozilla.org wrote:
Caitlin Potter wrote:
One reason it might make sense to throw, is people converting values
to string names for use as object properties. Reason you'd want to
throw would be to prevent accidentally making the key
One reason it might make sense to throw, is people converting values to
string names for use as object properties. Reason you'd want to throw would
be to prevent accidentally making the key useless (different from its
original Symbol value).
This is exactly the reason.
Of course,
Caitlin Potter wrote:
One reason it might make sense to throw, is people converting values
to string names for use as object properties. Reason you'd want to
throw would be to prevent accidentally making the key useless
(different from its original Symbol value).
This is exactly the reason.
On 1/2/15 9:33 PM, Axel Rauschmayer wrote:
Do people ever
compose a property key for an object out of several pieces?
On the web? All the time.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 1/2/15 9:40 PM, Axel Rauschmayer wrote:
Can you give an example?
get: function( num ) {
return num != null ?
// Return just the one element from the set
( num 0 ? this[ num + this.length ] : this[ num ] ) :
Can you give an example?
On 03 Jan 2015, at 03:34, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/2/15 9:33 PM, Axel Rauschmayer wrote:
Do people ever
compose a property key for an object out of several pieces?
On the web? All the time.
-Boris
35 matches
Mail list logo
