Replies: 8 comments
-
|
With or without Proxy/Reflect support 😄 ? |
Beta Was this translation helpful? Give feedback.
-
|
No objections here 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
Note that we have 4 open issues makes as regressions, two of which are against 1.7.15. May want to have those checked before a next release |
Beta Was this translation helpful? Give feedback.
-
|
@p-bakker good point, will try to find some time to have a look |
Beta Was this translation helpful? Give feedback.
-
|
Wrt #1755 and the idea to never as another language version (and at some point remove the old ones): I want to point out that a Rhino has some major EcmaScript incompatibilities, that affect day-to-day usage (so not some extra cases) These are (imho) incomplete/incorrect strict mode and incorrect const (and to a lesser extent) let behavior Fixing either of these has a likely potential of breaking existing JavaScript code out there that's running in Rhino, so when we get to fixing those, I doubt we can just fix them, without any sort of flag to toggle between the new, correct behavior and the old behavior. In my head we wood only switch to VERSION_ECMASCRIPT once we got these two things sorted, but now VERSION_ECMASCRIPT is just an alias for VERSION_ES6 (based on my own suggestions btw 🫣). So, wondering how others see us handling such backwards incompatible future fixes we'll like have to at some point, while not having a language version to be play with |
Beta Was this translation helpful? Give feedback.
-
|
Good points and important discussion. I do think that we run the risk of
breaking people when, some day, const starts to behave more properly, and
strict mode, and so on. I can think of two ways to look at this:
1. Hey, people knew about those parts of the language, and shouldn't be
surprised if something used to work because of a bug in the implementation
that should never have worked, like changing the value of a const.
2. No, it's not OK to break code every time someone upgrades Rhino.
If you like #1, then we leave everything as it is, we keep improving Rhino,
and we never change "language version" again.
If you like #2, then we make VERSION_ECMASCRIPT different from VERSION_ES6,
and whenever we add a new language feature, we ask ourselves if it will
break compatibility (like the const stuff) and put it behind that flag.
HOWEVER, I don't know what it'll take to make this all work -- it may be
too complex to try and make these things optional. If we do #2 then we will
end up learning that as we go along.
What do you all think?
…On Wed, Dec 18, 2024 at 11:04 PM Paul Bakker ***@***.***> wrote:
Wrt #1755 <#1755> and the idea to
never as another language version (and at some point remove the old ones):
I want to point out that a Rhino has some major EcmaScript
incompatibilities, that affect day-to-day usage (so not some extra cases)
These are (imho) incomplete/incorrect strict mode and incorrect const (and
to a lesser extent) let behavior
Fixing either of these has a likely potential of breaking existing
JavaScript code out there that's running in Rhino, so when we get to fixing
those, I doubt we can just fix them, without any sort of flag to toggle
between the new, correct behavior and the old behavior.
In my head we wood only switch to VERSION_ECMASCRIPT once we got these two
things sorted, but now VERSION_ECMASCRIPT is just an alias for VERSION_ES6
(based on my own suggestions btw 🫣).
So, wondering how others see us handling such backwards incompatible
future fixes we'll like have to at some point, while not having a language
version to be play with
—
Reply to this email directly, view it on GitHub
<#1743 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7I2ZL7WJSTABXM4PFEG32GJVWDAVCNFSM6AAAAABSZD72NOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRRGM3TGMA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
The const (and let) scoping and behaviour issues fixes are, as far as I was able to look into it, possible out behind a flag. As for the strict mode issues: not sure, the biggest challenge is the 'this' behavior in straight mode: default this is undefined, if 'this' is explicitly defined AND is a primitive value it should NOT be boxed. Implementing this requires imho die sure breaking changes to the scriptable interface and exactly how to prevent primitive boxing I have no clue about |
Beta Was this translation helpful? Give feedback.
-
|
See #1776 for a continuation of the above discussion |
Beta Was this translation helpful? Give feedback.
-
I think it's time for a release -- the pace of change has accelerated a lot (and thank you!)
I also think that this should be "Rhino 1.8.0". Here's why:
Now, if we're going to do that, are there any other structural things we want to introduce? One I can think of is replacing optimization levels with a single "interpreted / compiled" switch, with backward compatibility of course.
We could also set the default language level to "VERSION_ES6".
Some other discussions can be found elsewhere -- but I don't think that we're ready for "2.0" yet!
#1363
Beta Was this translation helpful? Give feedback.
All reactions