# This is type piracy, but is fully generic. If every package which wants to have its
# module callable uses this package, no problems with multiple definitions should occur.
(x::Module)(varargs...; kwargs...) = Val(x)(varargs...; kwargs...)
Nope, not only is it unconditionally type piracy, all packages using CallableModules would interfere with the potential Core/Base implementation and likely break something. This gets worse if CallableModules gets versions that aren’t strictly aligned with Julia versions. These sorts of piracy packages are tolerable as personal Base hacks, but not as widespread dependencies.
Secondly, this does not work as stated.
- Apps are documented to require the macro call
@main, which resolves to a function namemainafter some background registration for Apps and automaticMain.maincalls.@module_maindoes not do any of that and explicitly supports names other thanmain. - The premise that the shell command and the underlying module share a name is false. The documented Apps examples ALL specify names in the
[apps]section ofProject.tomlthat differ from the names of the package or submodules. Multiple App commands can be based on 1 module by configuring default command-line flags for the Julia process; in the general case, a command can specify much more than a Julia module. The-mflag of thejuliacommand for running a package’s@maindoes demand the package’s name, but that obviously compromises the visual parallel to a callable module.
I really don’t understand why you claim this package has anything to do with Apps or shell commands when it already does exactly what it’s named: make modules callable by forwarding to an annotated function. If the intent was to justify calling the module MyMod(args...) instead of a documented function MyMod.main(args...) or even an exported alias const approxappname = main among others, then you’ll need to figure something else out that doesn’t misinform.