domenic at domenicdenicola.com (2013-10-13T02:46:24.656Z)
On Oct 1, 2013, at 3:10 AM, Andreas Rossberg wrote: > OK, thanks for the summary, that makes sense. The one worry I have, > though, is that not tainting S.p.toString itself will miss cases where > code tries to convert some value x to a property name by explicitly > calling x.toString(). Currently, that works for everything but null > and undefined, so I assume that this pattern is used quite a bit. Do you think thing it really is? Any value (other than null and undefined) automatically converts to a string when used as a property selector. so there really isn't any reason (other than lack of knowledge) for someone to explicitly toString values before using them as a property key. On the other hand, there are plenty of reasons in other use cases where someone might explicitly toString because they actually want a string description of a value. Either choice we make here is probably going to trip up some code. I think what I've specified is the best set of trade-offs, but I willing to be convinced otherwise. I suspect hard evidence supporting either alternative is hard to find > There always is the generic Object.prototype.toString that can be made > to handle symbols. That is what V8 currently does (producing a string > just like you describe above). But this forces such code to be rewritten to special case Symbol values (assuming that they don't want, for example, string values and Arrays to display as [object. String] and [object Array]). Also, the spec. current says that O.P.toString for a Symbol returns [object Symbol] rather than Symbol(<descriptive string provided when created>). This is to keep it consistent with other types of values and code that expects O.p.toString to always produce the [object <name>] pattern.
On Oct 1, 2013, at 3:10 AM, Andreas Rossberg wrote: > On 30 September 2013 18:20, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >> The lastest draft throws when doing an implicitly ToString conversion [1] >> of a Symbol primitive value. This means that (aSymbol + "suffix") or >> ("prefix" + aSymbol) [2] will throw, which was the case that I believe >> people were most concerned about. >> >> ToNumber conversion of a Symbol value is currently specified [3] as >> producing a NaN for implicit numeric conversions of Symbols resulting in NaN >> values that will propagate through numeric computations. We could make >> ToNumber throw for Symbol values but NaN seems more consistent with the ES >> handling of invalid numeric conversions. >> >> ToBoolean of a String value is defined[3] to return true. This seems >> consistent with the rest of ES, although it would be easy enough to define >> this conversion to throw. >> >> This isn't current in the spec, but we should probably also make implicit >> string or number conversions of Symbol wrappers throw. We can to this >> simply by defining a @@ToPrimitive method [4] on Symbol.prototype that >> throws . > > OK, thanks for the summary, that makes sense. The one worry I have, > though, is that not tainting S.p.toString itself will miss cases where > code tries to convert some value x to a property name by explicitly > calling x.toString(). Currently, that works for everything but null > and undefined, so I assume that this pattern is used quite a bit. Do you think thing it really is? Any value (other than null and undefined) automatically converts to a string when used as a property selector. so there really isn't any reason (other than lack of knowledge) for someone to explicitly toString values before using them as a property key. On the other hand, there are plenty of reasons in other use cases where someone might explicitly toString because they actually want a string description of a value. Either choice we make here is probably going to trip up some code. I think what I've specified is the best set of trade-offs, but I willing to be convinced otherwise. I suspect hard evidence supporting either alternative is hard to find > >> Because, all of the appropriate implicit conversions produce error results, >> I didn't see any real reason why an explicit call to >> String.prototype.toString should throw. This certainly seems like a >> reasonable way for a program to explicitly convert a Symbol value to a >> string value for debugging, logging, or other proposes. This method is >> currently defined [5] to produce a string of the form "Symbol(<descriptive >> string provided when created>)". (modulo a small spec. bug) > > There always is the generic Object.prototype.toString that can be made > to handle symbols. That is what V8 currently does (producing a string > just like you describe above). > But this forces such code to be rewritten to special case Symbol values (assuming that they don't want, for example, string values and Arrays to display as [object. String] and [object Array]). Also, the spec. current says that O.P.toString for a Symbol returns [object Symbol] rather than Symbol(<descriptive string provided when created>). This is to keep it consistent with other types of values and code that expects O.p.toString to always produce the [object <name>] pattern. > /Andreas > > >> As discussed at the meeting, (new Symbol) will throw. This is accomplished >> by making Symbol's @@create method [6] throw. >> >> Object(aSymbol) is currently spec'ed to return a wrapper for the Symbol via >> a call to ToObject [7]. While idea of throwing was mentioned at the meeting, >> I'm not sure why it should be special cased to throw. This is how a >> programmer would generically convert primitive values to objects in >> situations where this is necessary. For example, >> "toString" in Object(expr) >> Note that a call to ToObject is also how the implicit conversions used to >> deference Reference values with primitive value bases (eg, aSymbol.foo) >> works. >> >> I'm not sure why my change log says (new Object(Symbol())) throws because >> that isn't actually in the draft [9]. Perhaps I was about to make that >> change, based upon the meeting minutes, and got interrupted or something. >> Regardless, it does need to do something. The most consistent thing would >> be to treat it, like all other primitive values, as a request to create a >> Symbol wrapper object. >> >> >> Allen >> >> >> >> >> [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.8 >> [2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-12.6.2.1 >> [3] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.2 >> [4] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.1 >> [5] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.4.3.2 >> [6] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.4.2.9 >> [7] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.9 >> [8] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.1.2.1 >> [9] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.1.2.1 >