-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
generix collections in Ruby land #3795
Comments
@kares fwiw I don't think we will ever escape that coercion away. I am also not even sure even if we could see something escape we would anyways. Once you convert it is really a different object at that point. I like the spirit of this enhancement. People who need the power will be willing to type their collections in such a way to prevent coercion. Most people will not care and will not do this but that is fine. This just gives us another level of control in how we interact with Java from Ruby. |
yeah, the escape was mostly a note for people expecting that if its all in Ruby it should behave differently. like the typed collection also wonder whether that syntax should disable any conversion e.g. |
Makes me wonder if we can just make a class method to return an uncoercing instance. At least for non-primitive types: Is there value to enforcing the type? I think primitives takes down a whole different rabbit hole... |
sounds like a simple good start and if it is to be implemented it would likely work on all Java proxies, yay :) |
Note: Java 9 does not include any generic reification, nor will the next couple years of updates (most likely). |
suppose a collection (or any other generic type) such as
java.util.ArrayList
never leaves Ruby-land.such as presented here: #2049 (comment) (implicit conversion leading to user confusion on times)
in cases such as those it might not be desirable for type conversions to be happening whenever a
java.lang.Object
boundary is seen (e.g.list.add Time.now
). but instead of tricky escape-analysis a reasonable way this could work is if target type information was available. some quick ideas :consequences of such wrapped Java types is that their need to become
__persistent__
to store additional generic type information. except maybe on Java 9 where there likely is to be a way to tell aSet<Integer>
from aSet<int>
The text was updated successfully, but these errors were encountered: