-
Notifications
You must be signed in to change notification settings - Fork 851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implementation of Reflect & Proxy support #1431
base: master
Are you sure you want to change the base?
Conversation
…he other symbol based methods)
milestone I reached
…/Reflect 20/139 (14.39%)]
SymbolKeys are shallowEq to symbols isArray has to take care of proxies
fix missing return for put traps
current status of the impl
|
As mentioned already somewhere, this code is in production in the HtmlUnit project (core-js) for a long time now. I like to update the stats for the current status of the test suite
and of course many other minor improvements. You can see the whole diff here HtmlUnit@c926d0f I think the number are still quite good and it's really frustrating to see this has to chance to get merged.... Or the other way around - @gbrail @p-bakker if you agree to merge this Reflect/Proxy impl, I will take the time and build a new pr that is mergable from this impl. |
I haven't been able to look into this, so dunno whether I agree this is mergeable at this moment I think the previous comments (see €1332) about the behaviour of Proxy/Reflect in this PR not being 100% standard compliant (due to issues/limitations elsewhere in Rhino) still stands, but maybe if I get a chance to look into the details I agree those issues shouldn't block merging inow However, even if the conclusion would be that we shouldn't merge this now, I'd like to keep this PR open and work towards being able to merge it in a hopefully not too distant future. So I hope you don't mind, but I'll reopen it |
By no means a thorough review, but:
Again: the above 2 comments are by no means a thorough review, but based on a quick glance at the updated test262.properties file |
Yeah, sorry, I sometimes lose track of how far along people collectively think that various PRs are, and like email, once they fall to the bottom of the list I sometimes lose track and I need a reminder. (There are tools that help send reminders and add more workflow to PRs -- perhaps we should adopt one!) Do you think that there are enough tests correctly passing in this PR to warrant merging it? It seemed like we were in an incomplete state from the comments. I'll look at the code and see what I think. |
As is mention several times (here and at other places) i gave up waiting for get this merged an i use this in HtmlUnit/core-js since December 2023. Not sure why you think this is incomplete. And i made all the statistics to show that this brings (from my point of view) the implementation of the two features in a similar state that we have for all the others (more than ~80% of the tests are passing). And there are some problems i can't solve because we have to be backward compatible - also discussed several times that i'm in favor of making a hard cut and break some backward compatible to be able to get closer to the current spec. But without that i see no chance to fix more tests. Good ideas are welcome |
Just a random test that fails and stands out to me is for example https://github.com/tc39/test262/blob/main/test/built-ins/Proxy/defineProperty/targetdesc-not-compatible-descriptor-not-configurable-target.js Just judging the testcode, I don't think it failing has to do with limitations elsewhere in the Rhino codebase, or am I wrong? I understand the frustration of it not getting merged, but I think we should aim to get each new feature as close as we can possibly get it to the spec, because the reality is that we otherwise never get to finishing up the details Quite likely your MR as it currently stand already correctly handles the majority of usecases correctly, but unfortunately, when it comes to specs, the devil is in the details.... Besides fixing more of the invariant checks like the one below, I could even see this only getting merged in a v2 (or otherwise behind a flag) if the delete trap cannot currently be implemented in a spec compliant way I'm afraid. Personally I hope to get a few things resolved in a 1.7.16 release, before we can start to focus on a v2.x.x release, particularly proper block-scoping and hopefully some strict-mode improvements |
Sadly I had trouble digesting this but it's very important work and I want to get it in to rhino. Unfortunately it will be a big job to resolve all the conflicts. Would you be willing if I am more diligent about merging it when it's mergeable? Otherwise I can spend time on it but it will take a bit. |
I can do that but not during the next weeks. Have some workshops and a bit of vacation... |
@@ -1581,7 +1581,7 @@ public void defineOwnProperty(Context cx, Object id, ScriptableObject desc) { | |||
* @param desc the new property descriptor, as described in 8.6.1 | |||
* @param checkValid whether to perform validity checks | |||
*/ | |||
protected void defineOwnProperty( | |||
protected boolean defineOwnProperty( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the change from void to boolean returnType? AFAICT all implementations/overrides of this method only ever return true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmm, found that the returnType is used in (at least) the reflectImpl.
I wonder if this is the way to go about it: the spec says defineProperty doesn't return a value, it just throws if there's an issue with defining the property
So I wonder if instead of changing the returnType of the method and always returning true, it would not be better to leave the existing impl. as is and in the Reflect.defineProperty just add a return true
after the call to defineProperty, as you already catch the exception and do a return false there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all new methods in the AbstractEcmaObjectOperations class have the additional Context argument that they are said to have |
@@ -3679,6 +3682,10 @@ public static boolean shallowEq(Object x, Object y) { | |||
if (y instanceof Boolean) { | |||
return x.equals(y); | |||
} | |||
} else if (x instanceof SymbolKey) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't x.equals(y) and y.equals(x) yield the same result, so you can so if (x instanceof symbolKey || y instanceof symbolKey)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that is possible but then the code relies on the assumption that x == null. This is correct here but the null check is so many lines above that it might be overlooked some day.
For me this is the more robust and more readable (because it starts no questions in my mind when reading) version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
k
} | ||
} | ||
|
||
// hack to set the right prototype before calling the ctor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe elaborate a bit on why this is considered a hack/why this hack is needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
return newScriptable; | ||
} | ||
|
||
private static Object defineProperty( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to return Object? It always returns a boolean, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is used by a LambdaFunction that expects an impl of Callable here - so i used the signature from Callable
Object prop = ScriptableObject.getProperty(target, (Symbol) args[1]); | ||
return prop == Scriptable.NOT_FOUND ? Undefined.SCRIPTABLE_UNDEFINED : prop; | ||
} | ||
if (args[1] instanceof Double) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think you already mentioned this elsewhere, but likely should check for Number, not Double
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in the new pr
Converted to draft, to indicate that this PR needs some work before it can be considered for merge, just to help the committers to be able to focus on what is really ready to merge |
sorry made a mistake during the update/rebase of #1332
This is the current version