I want to formalize a julep for a design idea, I am asking the help of the community , please read and criticise freely. The problems it is addressing: Type piracy: It is too easy to break code in module M, even without directly evaluating code into it, by adding methods to Base functions or any…

[image] StefanKarpinski: julia> module A export a, b, c a = b = c = 1 end Main.A julia> module B export c, d, e c = d = e = 2 end Main.B julia> module C using …A using …B import …B: c @show a, b, c, d, e end (a, b, c, d, e) = (1, 1, 2, 2, 2) Main.C I see. Thanks. But insisting on people not u…

Why are you writing production software that uses a name with one meaning and then does further using statements? I can understand that at the REPL but why would you do it in production code?

Once a name has a fixed meaning it cannot be changed. Using it at a point where the meaning is unambiguous resolves that meaning. This is inherently temporal. The recommended pattern in programs is to put the imports at the top all in one place. Then you’ll never encounter this issue except at the R…

Oh, excellent explanation! Thanks.

[image] StefanKarpinski: Why are you writing production software that uses a name with one meaning and then does further using statements? I can understand that at the REPL but why would you do it in production code? No, I don’t, this may then have been a misunderstanding coming from running …

A little further explanation. If a name is already ambiguous and you try to use it, then it is simply undefined. If you use a name when it’s unambiguous, that resolves its meaning. We can’t predict that you’re going to later do something that would cause it to become ambiguous, so the best we can do…

I think it would be great if this explanation plus this example was part of the documentation in https://docs.julialang.org/en/latest/manual/modules/#modules-1 Perhaps I missed it, but I couldn’t find an explanation of this and therefore I had an incorrect picture of how to resolve conflicts betwee…

Yes, it would be good if some of these more in-depth explanations were added to the documentation. This line looks rather confusing to me: The import keyword supports the same syntax as using, but only operates on a single name at a time. given that import module: a, b, c is correct, and it is …

I for one did not know this, and agree with @PetrKryslUCSD that a documentation update would help a lot. @rdeits made another suggestion to me in person regarding MethodErrors, and I’m hoping he’ll post it here, as it addresses another possible frustration. Yet another part of the (at least percei…

I’ve filed an issue about adding this to the docs somewhere: https://github.com/JuliaLang/julia/issues/27130 .

Julep: Taking multiple dispatch,export,import,binary compilation seriously

Internals & Design

rdeits May 17, 2018, 2:57am 114

Yup, I wrote it up here: Making method errors more helpful by indicating the defining module

Topic		Replies	Views
Function name conflict: ADL / function merging? Internals & Design proposal , namespaces	212	15275	April 30, 2018
Possibility of `local import` statements in future? Internals & Design scope	63	4127	May 2, 2018
"Meaning", type-piracy, and method merging Internals & Design type-piracy	68	5540	June 3, 2018
Proposal for SharedFunctions.jl package for optional dependency management Internals & Design	74	6044	May 7, 2019
Is Julia's way of OOP superior to C++/Python? Why Julia doesn't use class-based OOP? Internals & Design	146	34177	October 11, 2021

Julep: Taking multiple dispatch,export,import,binary compilation seriously

Related topics