2024年5月3日(金) 11:17 Lawrence Velázquez <v...@larryv.me>:
> If "import" were qualitatively different from "source" (say it
> integrated some sort of namespace functionality), then it would be
> more compelling.
That sounds interesting. It's a bit unrelated to the main discussion,
but I was wondering if it is possible to allow expansions in the
function name <name> in the function definition "function <name>
<compound>". Zsh allows it:
$ zsh -c 'ns=mynamespace; function $ns/util1 { echo This is util1; };
mynamespace/util1'
This is util1
This is just a hypothetical feature, but if we have a PATH-like
variable (e.g. BASH_FUNCTION_PATH or BASH_FUNCTION_NAMESPACE) for the
function name search, one can set « local
BASH_FUNCTION_PATH=mynamespace » to make `mynamespace/util1' visible
with the name `util1'.
But a problem of such a variable-based approach is that the namespace
is resolved by a dynamic condition (i.e. the variable in the context
when it is called) instead of the lexical context (i.e. where the
caller is defined or to which namespace the caller belongs). Maybe `.'
in BASH_FUNCTION_PATH can be treated as any namespace the caller
belongs to.
----
By the name "import", I expect also something like an include guard,
i.e., it loads the same file only once at most. I have a
shell-function implementation,`ble-import', in my framework. It
doesn't support namespace, but it supports the include guard. It also
accepts a setting for the paths to search. It also has a feature like
`with-eval-after-load' of elisp (or the "onload" event).
--
Koichi
