-
Notifications
You must be signed in to change notification settings - Fork 188
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
[interop] TruffleRuby does not allow binding modifications #2024
Comments
A workaround is to |
Current global variables are exposed with their name including So I'll do the same for writing to it, it needs to be Maybe we should change that, but then I'm afraid it might look confusing with e.g., accessing constants (not exposed in the top scopes currently), and potentially conflict with global methods (which can be read not written). |
I see your point...but on the other hand, |
To some degree I think identifiers have to be language-specific. In this case we want to differentiate methods on the main object, Object constants, and global variables, I think using the global variable syntax is a good way to achieve that. |
I agree with @fniephaus, I don't think using the member name with some special symbol is a good solution to this problem. If you need to add a $ you can also evaluate a ruby snippet instead. |
In TruffleSqueak, we have to deal with |
I think what would be more natural, especially in REPL/snippets-like contexts would be to read/write local variables of the "interactive Sources Binding". context.eval(Source.newBuilder("ruby", "foo = 14", "test").interactive(true).buildLiteral());
context.eval(Source.newBuilder("ruby", "foo", "test").interactive(true).buildLiteral()); // 14, already works
context.getBindings("ruby").getMember("foo") // 14, not yet supported Which is likely what most users want when accessing language bindings. It would probably make sense to try to get this to work non-interactive sources too, but that seems quite involved (notably, harder with #2025). |
…2024). PullRequest: truffleruby/1672
Steps to reproduce
context.getBindings("ruby").putMember("myGlobalObject", this)
throws an "Unsupported operation Value.putMember(String, Object)`" error.Expected behavior
myGlobalObject
is set in Ruby's globals and consequently accessible through$myGlobalObject
. Alternatively, Ruby'smain
object could be modified, but I'm not sure this makes sense.@eregon mentioned that this is simply not (yet) implemented.
/cc @tmillich @TheoRadig
The text was updated successfully, but these errors were encountered: