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

Add cop to replace Truffle::Type.coerce_to by Primitive.rb_to_int #2

Open
eregon opened this issue Apr 19, 2023 · 2 comments
Open

Add cop to replace Truffle::Type.coerce_to by Primitive.rb_to_int #2

eregon opened this issue Apr 19, 2023 · 2 comments

Comments

@eregon
Copy link
Collaborator

eregon commented Apr 19, 2023

Replace e.g. Truffle::Type.coerce_to obj, Integer, :to_int with Primitive.rb_to_int(obj)

@andrykonchin
Copy link
Owner

As far as I understand coerce_to is kind of deprecated method in favor of rb_convert_type (and basically Primitive.rb_to_int shares with rb_convert_type logic and helper methods - convert_type and conversion_mismatch).

Should we 1) get rid of the coerce_to completely and 2) replace rb_convert_type calls for Integer with Primitive.rb_to_int instead?

Also a bit off topic question - does it make sense to have such optimised conversion helpers (like Primitive.rb_to_int) that fallback to a generic conversion method for other common Ruby types - String, Hash and Array? When we add implicit type conversion for every core method argument - it may be more visible performance improvement.

@eregon
Copy link
Collaborator Author

eregon commented May 1, 2023

  • Yes, correct. coerce_to is from Rubinius and basically incorrect. rb_convert_type is correct but quite complicated, it would deserve a refactor to simplify it and probably rewrite it to Java (necessary to respect refinements), but not so high priority since coercion is rare.
  • IIRC, one concern is rb_convert_type is/might be slower than coerce_to.
  • Yes, exactly, we should avoid coerce_to/rb_convert_type(klass, method) and have Primitive.coerce_to_<method> (or convert_to_<method>). That means we have one such node per usage of that Primitive, which is exactly what we want. 99+% of them will just always receive already an instance of klass. For the remaining ones we'll either want to split for each caller (I'm thinking not worth it), or we accept the polymorphism, but in either case we only want it to affect that one method which is given different types for the same argument to be coerced, and leave the other methods as they are.

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

No branches or pull requests

2 participants