On Mon, Oct 1, 2012 at 12:00 PM, Rick Waldron <waldron.r...@gmail.com>wrote:
>
>
> On Mon, Oct 1, 2012 at 5:26 AM, Andreas Rossberg <rossb...@google.com>wrote:
>
>> On 30 September 2012 00:08, Brendan Eich <bren...@mozilla.org> wrote:
>> > I think this is too philosophical a discussion to result in a strong
>> reason
>> > to risk "symbol". Just my gut-check. Other TC39ers should weigh in
>> (Andreas
>> > R. especially).
>>
>> Type "symbol" would be my preference, but it is difficult to estimate
>> (for me) whether that involves a risk.
>>
>> However, this clearly is an issue beyond symbols alone. The same
>> problem re-arises whenever we have to add new primitive types in the
>> future. It doesn't seem like a sustainable strategy to fake any new
>> type ever into an object. Perhaps it is less harmful on the long run
>> if we took the chance to clarify _now_ that the set of strings
>> returned by 'typeof' is not fixed, and should not be treated as such?
>>
>
> +1 for "symbol", after reading through past concerns about adding new
> entries to typeof operator results, I'm not convinced that adding something
> completely new would have any negative side-effects. I'll be the first to
> admit that there are probably edge cases that I may have missed or didn't
> find, but I think the real risk is in piling new things on to existing
> typeof results when they questionably don't belong.
>
>
To try and make clear the risk that Brendan's alluding to think of it this
way: how many times have you written code that type-checks and assumes the
range of typeof is fixed? I've written code like this more times than I can
count:
if (attr == null) // null or undefined
else if (typeof attr == 'string') // string
else if (typeof attr == 'number') // number
else if (typeof attr == 'object') // whoops...
// handle arrays, objects, dates, regex, etc.
For code that falls through to 'object' it's possible the handler is
sufficiently generic, but changing the range of typeof changes assumptions
and *will* silently break old code, and for the same reason typeof 'null'
was nixed. This is a subtly backward-hostile change that doesn't fix
anything. It just introduces another barrier to es-next migration.
I'm convinced that typeof is a lost cause, but FWIW I believe symbols
themselves give us a way out of this mess.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
