How it feels to learn JavaScript in 2016

Logan Smyth loganfsmyth at gmail.com
Sat Nov 25 06:23:55 UTC 2017


Kai, that's not what backward-compatibility means though. It doesn't mean
that new code automatically works with older code, it means existing code
doesn't break when used alongside other existing code. Yes, adding new
features to the language means that assumptions made by old code may not
hold when used with new code. There is no way for existing code to break
due to the introduction of a new `typeof` return value, unless there's
actually new code introduced that _uses_ symbols. There is no way in the
world, in the general case, to introduce a change that will never
invalidate assumptions that someone has made at some point in the history
of an entire language. All TC39 can do is entire that new features are
exposed in such a way that assumptions made won't break as they are
currently used.



On Fri, Nov 24, 2017 at 10:09 PM, kai zhu <kaizhu256 at gmail.com> wrote:

> On 10/28/17, Frederick Stark <coagmano at gmail.com> wrote:
> > I'd just like to thank TC39 for not breaking compatibility. All the niche
> > old libraries I use that were written in ES5 still work in my ES6+
> projects
> > with no issues.
>
> introducing the new typeof Symbol() === 'symbol' does break backwards
> compatibility with many es5 libraries that default to 'object' type if
> typeof is not 'boolean', 'number', 'string', 'function', or
> 'undefined'.
>
> fortunately symbols are not used by everyday programmers (and rightly
> so), so its rarely encountered by these libraries.  if tc39 did really
> care about backwards-compat, they should've treated it as an 'object'
> type with a Symbol.isSymbol subtype-check like Array.isArray.
>
> this brings up another backwards-compat issue - what's the typeof for
> proposed BigInt / Int64 / Decimal?  i prefer treating them as 'number'
> or 'object' with subtype-checks BigInt.isBigInt et al., but Symbol has
> dangerously broken that precedent.  in general my opinion is tc39
> should freeze the existing set of typeofs (and use subtype-checks) for
> sake of backwards-compat and library/tooling stability.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171124/fc93d60e/attachment.html>


More information about the es-discuss mailing list