Standard builtins' prototypes and toString

[Allen Wirfs-Brock]

On Jun 18, 2014, at 11:04 AM, Brendan Eich wrote:

> I held back but can't any longer.
> 
> Till Schneidereit wrote:
>> 
>> 
>>    As far as I can tell, toString being an issue is just a conjecture
>>    that hasn't been tested. So, you could even go ahead an implement
>>    the corresponding toString methods as currently stands in the ES6
>>    spec. (throw for the wrong kind of object) which probably requires
>>    no change to their current implementation.
>> 
>> 
>> I'm somewhat opposed to this for two reasons:
>> 
>> One is that I'm pretty sure that it won't be compatible, whereas I'm optimistic about making Date.prototype a non-Date. There are tens of thousands of people using Nightly as their default browser, and while that makes it a good first target for experiments like this, it also means that we shouldn't do experiments where we're not optimistic about the outcome.
>> 
>> The other is that I still think the standard library shouldn't contain objects that throw when they're string-ified or value-ified.
> 
> Agreed on both points.
> 
> Changing Date.prototype from how it has stringified for (now) over 19 years [1] takes unknown probabiltiy times non-trivial cost risk, and Firefox Nightly won't be enough to find the content that breaks (sorry). Other engines would need to test and even put into release channels the change, and then we'd hope some smart site bug diag guru figures out the problem, if there is a problem.
> 
> Best way to avoid this is to avoid it. What's the profit in (b)?

Mostly about establishing the pattern for what should be done for other toString methods that are applied to the wrong kind of object or a non-instance prototype.  Not every object that could get a custom toString has a natural "0-value".

For example, what should Symbol.prototype.toString() do? (b) sounds like a good choice for it.  (c) is certainly ok, for Date.prototype but but we have other cases that need to be addressed.

Allen