implement setproperty! for modules
#44137
Conversation
It doesn't seem like there was any good reason for disallowing this. Especially now with #43671 merged I found myself wanting this.
simeonschaub
force-pushed
the
sds/module_setfield
branch
from
693086d
to
898f853
Compare
There was a problem hiding this comment.
We might want to improve this text error to say "imported variable" or something similar:
julia> stdout; Core.setfield!(Main, :stdout, stdout)
stdout = Base.TTY(RawFD(13) open, 0 bytes waiting)
ERROR: cannot assign a value to variable Base.stdout from module Main
Stacktrace:
[1] top-level scope
@ REPL[1]:1
|
Ok, I can look into what happens in codegen |
simeonschaub
force-pushed
the
sds/module_setfield
branch
from
b233d60
to
e599ae0
Compare
|
I think I want to tackle codegen in another PR. This should ideally be consistent with regular assignment to a global, where we currently just call into |
simeonschaub
added
status:merge me
|
What will happen if we call |
|
It ends up calling |
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
| if (order >= jl_memory_order_acq_rel || order == jl_memory_order_release) | ||
| jl_fence(); // `st->[idx]` will have at least relaxed ordering | ||
| set_nth_field(st, v, idx, args[2], isatomic); | ||
| if (st == jl_module_type) { |
There was a problem hiding this comment.
In recent discussions, @JeffBezanson considered getfield on modules to be a mistake and preferred a separate builtin instead for 2.0. Maybe we should avoid repeating this for setfield! and just go straight for a separate builtin?
There was a problem hiding this comment.
Maybe, but I think with the current getfield that would arguably be more of a special case, no? I'd be happy to change that though.
There was a problem hiding this comment.
@JeffBezanson should say which he prefers. I had suggested implementing the getbinding builtin right away also and just keeping getfield working with the intent to deprecate in 2.0. That way there wouldn't be an asymmetry and getfield would just have a bit of a legacy quirk.
There was a problem hiding this comment.
Yes I think we should have getglobal and setglobal!, eventually deprecate the use of getfield for this, and hook up getproperty and setproperty!. Triage also brings up that there is no way other than eval to declare a global const, though we do have set_binding_type!. I prefer "global" here, it just feels like jargon-y than "binding".
simeonschaub
added
status:triage
This replaces #44137. As discussed on triage, instead of supporting modules in `setfield!`, this adds two new builtins `getglobal` and `setglobal!` explicitly for reading and modifying module bindings. We should probably consider `getfield(::Module, ::Symbol)` to be soft-deprecated, but I don't think we want to add any warnings since that will likely just annoy people.
|
Closing in favor of #44231 |
This replaces #44137. As discussed on triage, instead of supporting modules in `setfield!`, this adds two new builtins `getglobal` and `setglobal!` explicitly for reading and modifying module bindings. We should probably consider `getfield(::Module, ::Symbol)` to be soft-deprecated, but I don't think we want to add any warnings since that will likely just annoy people.
This replaces #44137. As discussed on triage, instead of supporting modules in `setfield!`, this adds two new builtins `getglobal` and `setglobal!` explicitly for reading and modifying module bindings. We should probably consider `getfield(::Module, ::Symbol)` to be soft-deprecated, but I don't think we want to add any warnings since that will likely just annoy people.
This replaces #44137. As discussed on triage, instead of supporting modules in `setfield!`, this adds two new builtins `getglobal` and `setglobal!` explicitly for reading and modifying module bindings. We should probably consider `getfield(::Module, ::Symbol)` to be soft-deprecated, but I don't think we want to add any warnings since that will likely just annoy people.
This replaces #44137. As discussed on triage, instead of supporting modules in `setfield!`, this adds two new builtins `getglobal` and `setglobal!` explicitly for reading and modifying module bindings. We should probably consider `getfield(::Module, ::Symbol)` to be soft-deprecated, but I don't think we want to add any warnings since that will likely just annoy people. Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
It doesn't seem like there was any good reason for disallowing this.
Especially now with #43671 merged I found myself wanting this.