Deprecate module_name in favor of nameof(::Module)#25622
Deprecate module_name in favor of nameof(::Module)#25622JeffBezanson merged 3 commits intomasterfrom
Conversation
|
I do find the proposed behavior of the |
|
We could have a more general |
|
I really like |
|
There is a |
9c94ab7 to
6e8135c
Compare
|
Okay, I've introduced the |
6e8135c to
bb76caa
Compare
|
The doc build is failing because of this in DocStringExtensions: https://github.com/JuliaDocs/DocStringExtensions.jl/blob/22fe6a3ea2d8a194dc781ae8263a81c815e49926/src/abbreviations.jl#L137-L139 I'll submit a PR to change the loop variable name there. Edit: JuliaDocs/DocStringExtensions.jl#50 |
bb76caa to
b7a9134
Compare
|
Not sure yet what's going on with the Documenter/DocStringExtensions failure... |
|
Need Line 2 in 625923f |
|
Weird, I could have sworn I pushed that... |
6964570 to
285dfa0
Compare
|
Still getting the failure even with that change. |
285dfa0 to
67e9dc7
Compare
|
I'm not getting any errors while running locally so let's see what happens now... |
stdlib/REPL/src/REPLCompletions.jl
Outdated
| # as excluding Main.Main.Main, etc., because that's most likely not what | ||
| # the user wants | ||
| p = s->(!Base.isdeprecated(mod, s) && s != module_name(mod) && ffunc(mod, s)) | ||
| p = s->(!Base.isdeprecated(mod, s) && s != name(mod) && ffunc(mod, s)) |
There was a problem hiding this comment.
Ah, the downside of very generic function names --- conflicts with a local variable.
There was a problem hiding this comment.
👍 Yeah, it's a good idea to avoid "stealing" simple words like name when possible.
00c9369 to
a35c2d4
Compare
a35c2d4 to
b262a61
Compare
As suggested by @Sacha0 and @martinholters in #25436.
This deprecates
module_name(::Module)in favor ofSymbol(::Module)nameof(::Module).This is technically breaking, since currently theSymbolconstructor on modules falls back toSymbol(string(::Module)), which uses the entire module hierarchy (e.g.LinAlg->Symbol("Base.LinAlg")), and with this PR it would be the top name only (e.g.LinAlg->:LinAlg). The current behavior will still be available asSymbol(join(fullname(m), '.')).If this is accepted, I think we should also fold
function_nameanddatatype_nameintoSymbolconstructors.(I'm actually not super convinced that I like this, but I figured it's worth exploring.)