On Mon, Oct 1, 2012 at 9:23 AM, Dean Landolt <[email protected]> wrote:
> > > On Mon, Oct 1, 2012 at 12:00 PM, Rick Waldron <[email protected]>wrote: > >> >> >> On Mon, Oct 1, 2012 at 5:26 AM, Andreas Rossberg <[email protected]>wrote: >> >>> On 30 September 2012 00:08, Brendan Eich <[email protected]> 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. > The example you gave wouldn't be "symbol aware" anywhere else either... but let's say that this is part of some library code that accepts arguments from user code and a symbol is passed in - none of those conditions would be met (if typeof "symbol") and therefore nothing would happen. I don't think this is strong enough to block the possibility of a new typeof result. > > 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. > Adding a new result that accompanies a new language feature is not the same as changing something with 17 years worth of extant code. > This is a subtly backward-hostile change that doesn't fix anything. It > just introduces another barrier to es-next migration. > It's only "backwards-hostile" if user code intentionally creates hostile execution paths. Any comparison using "symbol" simply won't evaluate to true in older implementations... but then older implementations won't have symbols anyway. > > I'm convinced that typeof is a lost cause, but FWIW I believe symbols > themselves give us a way out of this mess. > I don't actually see what symbols themselves will do to be so heroic Rick
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
