Skip to content

#3180. Add JsAnyOperation.and tests #3216

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

Closed
wants to merge 2 commits into from

Conversation

sgrekhov
Copy link
Contributor

@sgrekhov sgrekhov commented Jun 5, 2025

No description provided.

Copy link
Member

@eernstg eernstg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Just wondering about the semantics of repeated executions of eval('var v = e; ...'): Is it safe to assume that nothing changes observably when it is executed for the second, third, etc time?

@srujzs, perhaps you could suggest another interop expert reviewer, just so we don't put too much of a burden on you? Otherwise, it would be great if you could take a look!

@srujzs
Copy link

srujzs commented Jun 10, 2025

Just wondering about the semantics of repeated executions of eval('var v = e; ...'): Is it safe to assume that nothing changes observably when it is executed for the second, third, etc time?

I'd avoid eval with var underTest = ... calls. The test relies on this evaluation occurring in a location such that the use of underTest can access that value. The compiler does not guarantee that. I'd instead just place it in the global context e.g. globalThis.underTest = so it doesn't matter where that eval call occurs.


At a meta level, I wonder if these tests are a bit overkill. There are tens of these operators, the implementation is quite direct, and there are a lot of values that can be used with these operators (any JS value, in fact!). Maybe it makes sense to test them all as thoroughly as we are, but I'm worried we'll be spending too many test cycles on something that will break in an obvious way if it ever changes. Thoughts, @eernstg?


@srujzs, perhaps you could suggest another interop expert reviewer, just so we don't put too much of a burden on you? Otherwise, it would be great if you could take a look!

I'm happy to keep taking a look at all the PRs! @nshahan has expressed interest in taking a look as well.

Expect.equals(globalContext["one"], JSObject().and(1.toJS));
Expect.equals(globalContext["string"], JSObject().and("s".toJS));
Expect.listEquals(
globalContext["a1"].dartify(),
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like the comments on the / PR, there's no reason to do dartify().

Expect.equals(globalContext["string"], JSObject().and("s".toJS));
Expect.listEquals(
globalContext["a1"].dartify(),
JSObject().and([].jsify()).dartify(),
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also like the comments on the / PR, prefer fetching the array/object from the global context here, on line 41, and on line 55. Same comments everywhere else.

eval(r'''
function foo() {}

var object = {};
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same meta-level comment as the / PR - instead of replicating this test file we can just use eval to have a different definition for the LHS JS value.

@sgrekhov
Copy link
Contributor Author

Replaced by #3223

@sgrekhov sgrekhov closed this Jun 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants