Re: Namespaces again (was: RE: PATCH: Add jobdirs association to parameter module)

[Zefram <zefram@fysh.org>]

Peter Stephenson wrote:
>I think Andrej was saying ${a.b} should be invalid, which I agree with
>since otherwise it complicates things mightily --- i.e, if there are any
>dots in a name, there must be one at the beginning.  Just allowing
>`.' separators might be enough for testing, but it's too much of a hack for
>normal use.  Unfortunately, catching all the relevant entry points to the
>parameter code to test this sort of thing tends to be rather a nuisance.

I don't see a problem with allowing ${a.b}.  In fact, I see it being
useful in scripts, and it doesn't complicate anything.  The shell's
special parameters (other than those with historically established names)
should all have names beginning with ".", but names not beginning with
"." that contain "." should be available to the user.

>It would be nice to get the full module name into the namespace, but
>perhaps ${.parameter.options} is a bit long.

No need.  Put the parameters from the zsh/* module namespace into the
${.zsh.*} parameter namespace; we can manage the clashes as we already do.
Other module writers can do the same kind of namespace tricks.  We could
formalise that: parameters whose names begin with "." have a hierarchical
namespace managed in the same way as the module namespace and with the
same top-level delegations.  That would give every potential module
writer some guaranteed parameter namespace.

Next possibility: add parameters ${.zsh.path}, ${.zsh.module_path}, etc.,
as aliases for $path, $module_path and so on.  Then we can have an option
to make the non-. names non-special.  Only zsh-specific scripts could
do that, of course, but the freeing of the namespace is a non-trivial
advantage that would make it desirable.

>                                                 mapfile is perhaps the
>only candidate, but then ${.mapfile.what?}, or can we get away with
>${.mapfile} ?

If following the module namespace, make it ${.zsh.mapfile}.  If we want
to add other parameters to that module later, there's nothing to stop
${.zsh.mapfile.foo} coexisting.

-zefram