@Sam Ruby: I think we should indeed go for an extra character. In the proposals that result in `?[` and similar, it may be possible to define correctly in the spec, but it would indeed be non-obvious for humans to interprete, and potentially make the parser slower.
I proposed `??` as a unique double character, but `.?` could also work, and perhaps be easier to read (`??` is a bit heavy on the eye with two big glyphs). The only confusion that could happen (AFAICS) is when mixing the decimal point with the ternary operator. But the spec already states that a digit followed by a point is always a decimal point (which is why we need to do `(255).toString(2)`). So the parser only has to look very locally to find the correct interpretation. And it helps humans too. @Brendan: yes, soaking up all null/undefined values will probably be wanted by some. But personally, I'd prefer to show in my code where exactly null values can be expected, and where stuff should always be defined. Using the null-soaking syntax too much might result in code that's hard to debug (some null is coming from somewhere, but nobody has an idea from where, as it's just propagating through all accessors). Thanks for all your comments. Regards, Sander 2015-06-02 20:30 GMT+02:00 Brendan Eich <bren...@mozilla.org>: > Sam Ruby wrote: > >> I think that the problem here isn't that it is ambiguous, it is that >> it isn't obvious. >> > > Fair point! > > Something that might be more obvious but requires >> an additional character: `orders.?[client.key].price`. >> > > That's not bad. The whole proposal may founder, though, on "grawlix" > objections. > > And some still want the ?obj.foo.bar to "soak" null/undefined obj and > missing foo or null/undefined value of foo. CoffeeScript fans for sure, but > it's in principle and practice at least as valid a use-case as obj.?foo is. > > /be >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
