search

oracle / graaljs

A ECMAScript 2023 compliant JavaScript implementation built on GraalVM. With polyglot language interoperability support. Running Node.js applications!
Universal Permissive License v1.0
1.77k stars 189 forks source link

Q: ANNEXB disable story #847

Open ecki opened 2 days ago

ecki commented 2 days ago

There is a lot of harsh critic of the legacy functions and behavior of AnnexB in AnnexB, so it feels natural to disable it (in standalone script engine). However the extend is not completely clear from the doc, and before I search the usage of the option in the source, is there some mission statement?

I would feel a bit uneasy in removing escape() and unescape(), can we make the disable option more granular and separate the syntax improvements from the replaced built in functions and the less critical ones? js.disable-AnnexB-html or js.enable-AnnexB-escaling or some such?

https://tc39.es/ecma262/#sec-additional-ecmascript-features-for-web-browsers

All of the language features and behaviours specified in this annex have one or more undesirable characteristics and in the absence of legacy usage would be removed from this specification…

These features are not considered part of the core ECMAScript language. Programmers should not use or assume the existence of these features and behaviours when writing new ECMAScript code. ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser

iamstolis commented 2 hours ago

is there some mission statement?

AnnexB exists for legacy reasons only i.e. to keep the code (that uses the features already) working.

can we make the disable option more granular

I am sorry, I don't understand what use-case would more granular options for AnnexB solve exactly. If you are not sure that the code that you execute does not depend on AnnexB features then it is better to keep them enabled. Otherwise, it is a good idea to disabled AnnexB features completely, no?

ecki commented 1 hour ago

Well, if Graal thinks this is for legacy reasons (and I would fully agree, especially given the actual changes mostly make sense), why not disable it by default like the specification suggests?

I would like to do so, but it might be needed for one feature or the other. So beeing able not to have to use the more harmful parts (or the more obvious parts like the html compatibility) seperately looks like a good alternatively to keep it entirely enabled.

(Having said that it would be good to know what stuff is really turned off, like is it altering the syntax or only removing the String.properties, or…)