Re: unset does not remove functions like a[b] unless -f is specified

[Koichi Murase]

2023年2月4日(土) 19:41 Robert Elz <kre@munnari.oz.au>:
> [...]
>
> Incidentally, while I understand your desire to make function namespaces
> using '/'

I think this is a separate interesting discussion, so let me reply in
a separate mail.

I guess you understand me, but just to be sure, I'm not desiring to
make it in the POSIX standard but just desiring, if possible, a room
where an implementation can choose its behavior so that I can rely on
them in my Bash scripts (not POSIX scripts).

> (though some other character, maybe @ or % or something might
> have been a better choice)

As I have explained in another reply, the slash had an affinity with
the user experience of the command completion system. It was also
easier for me to categorize the public and private functions. When I
made the decision to entirely switch to slashes at an early stage, I
didn't see any effective difference between / and @, %, or whatever in
Bash's behavior, which is the reason that I didn't think @ or % is
better then. If I knew that the Bash could change its behavior, I
wouldn't have chosen a slash, but I couldn't imagine that the Bash
might partially stop the support leaving other frequently used
characters, such as hyphens, periods, and colons.

> but how does your system work with global
> variables that those functions might need?

This is a good question. First of all, I do not use global variables
so much because I'm using the function names with slashes in Bash
scripts, and Bash has local variables. Nevertheless, I occasionally
need to store information in global variables. In that case, I need to
choose a different naming convention for the variable names.
Currently, I'm using roughly the form of
`_<FrameworkName>_<ModuleName>_<VariableName>'. To avoid conflicts, it
is sufficient to assume that the other frameworks and the applications
do not use the variables starting with `_<Frameworkname>_...`. The
function names and the variable names do not need to be the same as
far as the namespace is effectively separated by the prefix
`_<FrameworkName>'. There is no 100% guarantee that no other scripts
use the same prefix, but so far it seems to work fine. The conflict
rate is so small that I can manage it after noticing it.

--
Koichi