Proxy and Reflect implementation #1637
Conversation
rbri
force-pushed
the
Proxy_and_Reflect
branch
from
e195119
to
ec6f9dd
Compare
|
Not possible to continue with the previous PR? This way we may lose the (unresolved) comments |
rbri
force-pushed
the
Proxy_and_Reflect
branch
2 times, most recently
from
1e1aa7b
to
b5cf850
Compare
|
As promised i have recreated the Proxy/Reflect stuff based on the current status of the impl. From my point of view this is already in a state that can be merged - i will not really work on this because i have some other priorities. Will try to rebase from time to time.... |
Could you elaborate on which breaking changes are needed to make Proxy more spec-compliant? From looking at all comment on this and the two preceding PRs, I gathered the following: Included breaking change: defineProperty now returns boolean instead of void Are there more changes that ought to be made, but that you held off on as they would constitute a breaking change? Also, some of my previous comments remain unanswered. Any chance you can have a look at them?
And wrt to whether this is mergeable in its current state or not: I worry that there are details of the spec that haven't been implemented yet and that do not relate to requiring breaking changes, for example (some completely random checks on currently failing tests):
Not trying to be pedantic about this, I really wanna see Proxy support merged (heck, I opened the issue about it 8 and a half years ago :-) ), am just worried about A: merging something that isn't as spec compliant as it can be, meaning we'll have to make (potentially) breaking changes later and B: that if we don't take care of the details now, we'll never get to tme |
rbri
force-pushed
the
Proxy_and_Reflect
branch
5 times, most recently
from
61807dd
to
f85dcbf
Compare
rbri
force-pushed
the
Proxy_and_Reflect
branch
from
f85dcbf
to
7096411
Compare
|
Current stats
|
rbri
force-pushed
the
Proxy_and_Reflect
branch
from
f493744
to
71030b0
Compare
|
Can you guys (really @rbri and @p-bakker) try and keep status of "open issues" here? At some point very soon I really want to pull the ripcord and merge this and I don't know where we stand regarding @p-bakker's comments a few commits ago. This all raises the question about big PRs versus feature branches -- we have raised the bar recently on merging incomplete stuff (versus, say, when I put in the native array stuff 10 or so years ago), which is good, but now we're encouraging these gigantic PRs that change dozens of files and require a dedicated coder (thanks, @rbri) with the patience to constantly rebase their stuff... |
|
@gbrail will spend some time tomorrow to (hopefully finally) write some responses to @p-bakker comments. If this help to get this merged.... Outside of this i really support of working in smaller steps. I guess that some of the growing PR's are like that because we need sooo long to get them merged. But this is just my theory... |
|
Yes, sometimes we are slow to merge things, but we do what we can.
If there were a way to add a new language feature in smaller parts, while
leaving it disabled (or via feature flag) until complete, that would help a
lot. I bet that we could come up with some way to do that.
|
|
Now that everybody complains about the downsides of agile we have to start to work more agile in this project :-D :-D But it is great to see that a bunch of peoples working hard to bring this forward. |
|
I think we have to make a distinction between big PRs and PRs touching a lot of files This PR is big in that the spec for Proxy and to a lesser extend Reflect are big, with a lot of nitty, gritty details, but most of those details are just within their respective implementation classes. It doesn't touch a ton of files and where it does, some of those changes could IMHO be merged separately. On the flipside, we recently we had a bunch of PR that all touched upon the same areas, which led to a lot of (complicated) rebasing being required, but as detailed elsewhere, at least on the EcmaScript-language front we don't have ton of missing features (albeit those missing being quite big). The fact that we have test262.properties to record the state of Rhino passing the Tests262 testsuite, which means it'll have changes in any PR that does something on the EcmaScript level plus the fact that some of the stuff being worked on (like in this case Proxy & Reflect) that are used throughout testcode and not just the test related to specific implementation itself is just a fact I don't see we can eliminate, until such time Rhino is more standards-compliant and the 'problem' guess away by itself I do think it's good that we are more vigilant to making sure that any EcmaScript-related stuff that gets merged is as standard-compliant as possible and properly identify the areas where is not and then create follow-up cases to address those areas. IMHO that is the only way forward if we want to get closer to being spec-compliant. |
|
Also: its possible to put comments behind entries in test262.properties. Maybe we ought to use that to refer to cases if we know the reason why a particular test doesn't pass, but can't be make to work with the context of the PR at hand |
…62.properties with jdk 11 and some minor fixes
rbri
force-pushed
the
Proxy_and_Reflect
branch
from
71030b0
to
5a8f0f3
Compare
Regarding the still failing tests
For the remaining tests i hope someone more clever than i can jump in. @gbrail, @p-bakker if you like to see someone to work on further improvements in this area, i fear you have to merge this - otherwise it might be too hard to jump in. But who knows.... And finally i have prepared a new PR #1660 that is again a single commit based on the current head. I guess it will be simpler to merge. (as soon as all tests are passing i will mark this as draft to increase the confusion ;-)) |
Next try on the long story.... see #268
This is the follow up of #1431.
Closes #268