Java actually has similar semantics to JS here--you can dynamically load a class which subclasses another class, and forces the JVM to deoptimize unchecked inline calls to particular concrete methods. Again, like going back and making the method virtual. I guess it comes up less.
-
-
Replying to @littledan @robpalmer2 and
What helps in Java is that class members and methods can't change once the class is created. You don't have to worry that, say, an object stops being a subclass of an object in the middle of a method call
1 reply 1 retweet 3 likes -
Replying to @natashenka @robpalmer2 and
Yes, JS is "worse" in this sense. The ease of implicitly creating new hidden classes leads JS JITs to often have an open world assumption when examining the class hierarchy, whereas Java JITs can be more comfortable with a closed world assumption and fewer checks.
1 reply 0 retweets 1 like -
Replying to @littledan @natashenka and
(Good morning) JS much worse than Java. But, the whole basis of modern JS engines (harkening back to Self) is that most programs locally behave as if closed world & this condition is detectable via runtime analysis and then optimized accordingly.
1 reply 0 retweets 2 likes -
Replying to @awbjs @littledan and
This is very bad for startup; and with frameworks polymorphism Ian often so bad that the optimizing compiler is out of the picture altogether. Designing relying on the optimizing compiler is not what you should do for a language where startup performance is vital
1 reply 0 retweets 2 likes -
Replying to @tverwaes @littledan and
Langauge implementors have to implement (hopefully well) the language they are given, not that language they wish they were given. The fundamental dynamic nature of JS was set in stone over 20 years ago.
1 reply 1 retweet 2 likes -
Replying to @awbjs @littledan and
That nature is less problematic than features that were added much later unfortunately. E.g. species and toStringTag
1 reply 0 retweets 4 likes -
Replying to @tverwaes @littledan and
Oh really? An extra lookup in what is largely a debug method and a extra, outside of loop, lookup in array functions are more problematic then unconstrained mutability of the prototype chain?
3 replies 0 retweets 0 likes -
So why is it so hard to admit that some ES6 features were designed with only hypothetical use cases in mind?
1 reply 0 retweets 5 likes -
Use cases for new language features are always hypothetical until actually available in the languages. Part of the job of a language designer is to identify unsupported use cases and figure out how to support them. Experience with other langs is one source.
1 reply 0 retweets 0 likes
I disagree. By working with the community we can most definitely get data on developer demand for particular features.
-
-
sure, but the community doesn’t necessarily think through 2nd/3rd requirements. EG, may ask for subclass able built-ins but haven’t thought about all the details.
2 replies 0 retweets 1 like -
It's true, TC39 has to think through the detailed edge cases and implications if others don't raise the issues. But then, we can follow up with both the JS community and implementers to ask if those are good decisions for them, and iterate if needed.
1 reply 0 retweets 4 likes - 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.