Please explain syntax

[govorunov]

@Liso

Do you now something like this (do it in REPL)?

julia> @edit Char(1)

This is a cool feature, but it does not help to organize code. Besides it only works when Char(::Number) is already in context. Not all development is done in REPL. Try writing a web server and you will soon realize virtues of a fully functioning debugger, etc.

[Liso]

@oxinabox

Namespaces prevent you doing dispatch.

Is it really true?

julia> import LinearAlgebra

julia> Base.show(a::LinearAlgebra.SingularException) = "A"

julia> show(LinearAlgebra.SingularException(1))
"A"

And you still could pollute global namespaces with using if you like!

julia> using LinearAlgebra

julia> show(SingularException(1))
"A"

[Tamas_Papp]

@govorunov

So the sophisticated system you are describing works for packages, not modules.

It works for code loading, via packages, which contain modules. Did you read the documentation I linked above? Specifically, in Julia, a package is an

an independent, reusable collection of Julia code, wrapped in a module

@govorunov

Yet Julia also has modules for some reason

Yes. The reason is namespace management.

@govorunov

I think it is convenient being able to reflect modules structure with file/directory structure within one package/program.

Sure. Use submodules. Eg see code in Base for a real-world use case.

[bennedich]

@govorunov

To my understanding packages and modules are generally different things. One package may contain multiple modules and sub-modules. Can it contain sub-packages?

Actually yes, there is a concept of sub-projects, which have their own sets of dependencies, and can contain their own top-level modules. We are using this for our test code – it’s its own project, with its own dependencies, including a dependency on the main package, and contains its own top-level module. By making it a sub-project, we can achieve this while keeping it all in the same git repository, and without including the test-specific dependencies in the main package. Although this technique works decently well, it feels a bit under-developed at the moment. More details in this post.

[dfdx]

So if I understand you correctly, you want to organize your own code as follows:

src/
  |-- MainModule.jl
  |-- Submodule1.jl
  |-- Submodule2.jl

Then import submodules inside MainModule.jl as:

using Submodul1
# instead of 
# include("Submodule1.jl")
# using Submodule1

And later use then from another package as:

using MainModule.Submodule1

If so, then you can already do it with the only exception of include/using pair which can be combined into a macro, e.g.:

@using_module Submodule1

If it’s not what you want, please describe exactly the workflow you want.

[govorunov]

I will do the macro. Thank you!

[govorunov]

One more question, sorry.
How come

(::Type{T})(x::Number) where {T<:AbstractChar} = T(UInt32(x))

does not call itself infinitely?

[dawbarton]

In this case it is because there exists a more specific method for arguments of type UInt32. To see this consider

julia> @which Char(1)
(::Type{T})(x::Number) where T<:AbstractChar in Base at char.jl:48

julia> @which Char(UInt32(1))
Char(u::UInt32) in Base at char.jl:146

It does mean that you have to be careful when creating your own subtypes of AbstractChar to create all the required methods or you will, as you say, get an infinite loop.