Skip to content
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

Accept Array-like objects seamlessly in builtins #3817

Merged
merged 7 commits into from
Oct 25, 2022

Conversation

hubertp
Copy link
Contributor

@hubertp hubertp commented Oct 20, 2022

Pull Request Description

Most of the time, rather than defining the type of the parameter of the builtin, we want to accept every Array-like object i.e. Vector, Array, polyglot Array etc.
Rather than writing all possible combinations, and likely causing bugs on the way anyway as we already saw, one should use CoerceArrayNode to convert to Java's Object[].
Added various test cases to illustrate the problem.

Checklist

Please include the following checklist in your PR:

  • The documentation has been updated if necessary.
  • All code conforms to the
    Scala,
    Java,
    and
    Rust
    style guides.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed: Enso GUI was tested when built using BOTH
      ./run ide build and ./run ide watch.

@hubertp hubertp changed the title Accept Array-like objects seamlesly in builtins Accept Array-like objects seamlessly in builtins Oct 20, 2022
@hubertp hubertp force-pushed the wip/hubert/builtins-array-conversion-183266964 branch from ed5340b to e2207aa Compare October 20, 2022 14:40
Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

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

Great.

@hubertp hubertp marked this pull request as ready for review October 21, 2022 12:05
hubertp and others added 6 commits October 25, 2022 11:48
Most of the time, rather than defining the type of the parameter of the
builtin, we want to accept every Array-like object i.e. Vector, Array,
polyglot Array etc.
Rather than writing all possible combinations, and likely causing bugs
on the way anyway as we already saw, one should use `CoerceArrayNode`
to convert to Java's `Object[]`.
Added various test cases to illustrate the problem.
Co-authored-by: Jaroslav Tulach <jaroslav.tulach@enso.org>
Moved location-dependent test cases out of Meta spec. That way we don't
have to update them every single time we add new test to Meta.
@hubertp hubertp force-pushed the wip/hubert/builtins-array-conversion-183266964 branch from ea23daa to a4b8913 Compare October 25, 2022 10:04
@hubertp hubertp requested a review from radeusgd October 25, 2022 10:04
@hubertp hubertp added CI: Ready to merge This PR is eligible for automatic merge and removed CI: Ready to merge This PR is eligible for automatic merge labels Oct 25, 2022
…ion/builtin/mutable/CoerceArrayNode.java

Co-authored-by: Radosław Waśko <radoslaw.wasko@enso.org>
@hubertp hubertp added the CI: Ready to merge This PR is eligible for automatic merge label Oct 25, 2022
@mergify mergify bot merged commit f6379fb into develop Oct 25, 2022
@mergify mergify bot deleted the wip/hubert/builtins-array-conversion-183266964 branch October 25, 2022 12:44
hubertp added a commit that referenced this pull request Jan 4, 2023
Most of the problems with accessing `ArrayOverBuffer` have been resolved
by using `CoerceArrayNode` (#3817).
In `Array.sort` we still however specialized on Array which wasn't
compatible with `ArrayOverBuffer`.

Added a specialization to `Array.sort` to deal with that case. Because
one cannot use a custom comparator with primitive (Java) arrays there is
a conversion needed. It's a necessary penalty if we want to keep
`ArrayOverBuffer` around.

Also fixed an example in `Array.enso` by providing a default argument.
hubertp added a commit that referenced this pull request Jan 8, 2023
Most of the problems with accessing `ArrayOverBuffer` have been resolved
by using `CoerceArrayNode` (#3817).
In `Array.sort` we still however specialized on Array which wasn't
compatible with `ArrayOverBuffer`.

Added a specialization to `Array.sort` to deal with that case. Because
one cannot use a custom comparator with primitive (Java) arrays there is
a conversion needed. It's a necessary penalty if we want to keep
`ArrayOverBuffer` around.

Also fixed an example in `Array.enso` by providing a default argument.
hubertp added a commit that referenced this pull request Jan 9, 2023
Most of the problems with accessing `ArrayOverBuffer` have been resolved
by using `CoerceArrayNode` (#3817).
In `Array.sort` we still however specialized on Array which wasn't
compatible with `ArrayOverBuffer`.

Added a specialization to `Array.sort` to deal with that case. Because
one cannot use a custom comparator with primitive (Java) arrays there is
a conversion needed. It's a necessary penalty if we want to keep
`ArrayOverBuffer` around.

Also fixed an example in `Array.enso` by providing a default argument.
mergify bot pushed a commit that referenced this pull request Jan 9, 2023
…s the Array (#4022)

Most of the problems with accessing `ArrayOverBuffer` have been resolved by using `CoerceArrayNode` (#3817). In `Array.sort` we still however specialized on Array which wasn't compatible with `ArrayOverBuffer`. Similarly sorting JS or Python arrays wouldn't work.

Added a specialization to `Array.sort` to deal with that case. A generic specialization (with `hasArrayElements`) not only handles `ArrayOverBuffer` but also polyglot arrays coming from JS or Python. We could have an additional specialization for `ArrayOverBuffer` only (removed in the last commit) that returns `ArrayOverBuffer` rather than `Array` although that adds additional complexity which so far is unnecessary.

Also fixed an example in `Array.enso` by providing a default argument.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants