-
Notifications
You must be signed in to change notification settings - Fork 16
[RFC] monkey patch setindex #107
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR LGTM! I did want to use this occasionally, too (e.g., https://github.com/queryverse/VegaLite.jl/pull/191/files#r333284529).
Since
BangBang
also needs this and implements it much better then this PR, should that function be part ofConstructionBase
? Or should it be in aNoBang
package?
I think it'd be a slight stretch to put this in ConstructionBase
. We can also extract NoBang
as a separate "base" package and put it in JuliaObjects organization (with a better name; maybe something like ImmutableInterfaces
). But, as a short term solution, I think it's good to have a copy of definition in Setfield
, especially until when there is a need for overloading setindex
.
(For a long term solution, I hope this becomes a part of Julia Base. FYI, I sent a PR/RFC in Julia Base JuliaLang/julia#33495 to add similar definitions. But it does not get any attention yet.)
BTW, a super nitpicky comment: I don't think this PR includes any monkey patching or type piracy. It just cleanly extends Base.setindex
without modifying (patching) global state by introducing internal Setfield.setindex
.
I made #108 to add BangBang-like type-widening semantics to |
I think it would be a good idea to move this to a separate package in the JuliaObjects organization. I am fine with |
After implementing #108, I realized that it's hard to do this outside of Base. We either need to:
But since option 1 is the only direction that is doable on our side, I guess we don't have much choice but to use option 1... ATM, there is a small "circular" dependency from BangBang to NoBang for implementing Meanwhile, how about just merging this PR as-is? I guess there are not many demerits for doing this? |
I agree. Can you maybe rebase JuliaLang/julia#33495 and we try to convince people to merge it? |
I resolved the conflict and also ping people in #arrays channel of slack. (But this never worked...) |
It is a recurring annoyance for me that I want to
@set arr::Array
and cannot do it.Should we allow doing that?
Should we use our own variant of
Base.setindex
?Since
BangBang
also needs this and implements it much better then this PR, should that function be part ofConstructionBase
? Or should it be in aNoBang
package?What do you think @tkf?