Thank you very much Jakob for showing me the right direction!
Am Mittwoch, 6. November 2019 11:54:45 UTC+1 schrieb Jakob Kummerow: > > To get involved with future ECMAScript specifications, TC39 >>> <https://github.com/tc39> is the place to go. Even if all V8 >>> contributors agreed to change some feature, we couldn't just implement >>> something that contradicts the spec. >>> >>> >> Yes, you can't? Even if you preserve backward compatibility? Why not add >> features which can be used by all devs >> who are sure their code only runs on v8? >> > > OK, to be precise: of course technically we *could*, but we do not *want* to > diverge from the spec, because we believe that fracturing the ecosystem is > bad (for a variety of reasons). > > Note that it's relatively easy to come up with things one would do >>> differently if one were to design JavaScript from scratch; it is much more >>> difficult to change anything in the language that already exists because of >>> backwards compatibility: we wouldn't want to break existing, previously >>> working code (which might be unmaintained, or whose maintainers don't have >>> time or willingness to spend time updating their code just because someone >>> thought it would be an improvement if the language's semantics changed). So >>> you're left with adding new things, but adding something new never "fixes" >>> something else that's already there -- for example, just because === is >>> useful doesn't stop people from complaining about ==. >>> >>> >> Yes, you are right. Nevertheless I think there a ways to improve the core >> language. >> > > Of course there are! Specifically, participating in TC39's work is *the* > way to improve JavaScript. They even have a document explaining the > process: https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md > > Changing JSON (even just additively) is even more difficult than changing >>> JavaScript itself, because JSON is used so ubiquitously even in >>> non-JavaScript scenarios. For example, that's the reason why JavaScript >>> BigInts are not directly representable in JSON. >>> >>> >> Thank you for this hint. BigInt in JSON seems to be supported by python: >> >> >> https://github.com/guettli/lets-fix-js/blob/master/README.md#javascript-support-for-bigints >> >> I guess this is a JS issue, not a JSON issue. But I am unsure (have not >> read the specs in detail). >> > > Indeed, I think it would be beneficial for your efforts if you did some > research on existing issues and constraints. JavaScript supports BigInts > just fine. Regarding support in JSON, there is a lot of existing discussion > that led to this decision, e.g. at > https://github.com/tc39/proposal-bigint/issues/24 -- I'm sure if you look > around you'll find even more people arguing in all directions. > > My current goal is to gather ideas what could be improved in JS and JSON. >> I am particularily interested in things which can't be fixed by wrappers >> like TypeScript. >> After writing, someone created the first issue here: >> https://github.com/guettli/lets-fix-js/issues >> I hope more devs still believe that the future can be influenced. >> > > The future can certainly be influenced; the way to influence JavaScript's > future is to participate in TC39's work. V8 is represented there too; any > decisions about language features/changes will be made there, not on this > mailing list. > > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/9e104d43-c417-4a15-9244-4b61daa12040%40googlegroups.com.
