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

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

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > - What exactly would we gain by using different tables?
> 
> It's really an internal matter.  If you can give the same impression easily
> without that's probably OK.
> 
> > - In which way would they remain `invalid'? Especially from a user's
> >   point of view -- who should still be able to say `.a.b=c'.
> 
> 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.

Ah, I see. Yes, that sounds reasonable.

>  Unfortunately, catching all the relevant entry points to the
> parameter code to test this sort of thing tends to be rather a nuisance.

Indeed.

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

I've been thinking some more... maybe we should only use it for
logical grouping. E.g. the parameters from zle ($BUFFER etc.) should
be $.zle.buffer etc. and the ones from the zleparameter module should
use the same prefix ($.zle.keymaps seems to make a lot more sense to
me than $.zleparam.keymaps or even $.zleparameter.keymap). And then
the parameter module could probably use `$.zsh.' as the prefix.

I think the result would be that the names say what they give access
to instead of saying where they come from - and I hope user's will
find this much less confusing.

> I think it's still early enough days with the parameter module to make this
> change without too many people throwing themselves off millennial
> landmarks.  We should decide if others need it.  mapfile is perhaps the
> only candidate, but then ${.mapfile.what?}, or can we get away with
> ${.mapfile} ?

Then there is the question how far we want to go. E.g. should we
change $BUFFER and friends? The special completion parameters like
$.comp.state, $.comp.prefix and so on?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Zefram]

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

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

[Peter Stephenson]

Sven Wischnowsky wrote:
> - What exactly would we gain by using different tables?

It's really an internal matter.  If you can give the same impression easily
without that's probably OK.

> - In which way would they remain `invalid'? Especially from a user's
>   point of view -- who should still be able to say `.a.b=c'.

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.

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

I think it's still early enough days with the parameter module to make this
change without too many people throwing themselves off millennial
landmarks.  We should decide if others need it.  mapfile is perhaps the
only candidate, but then ${.mapfile.what?}, or can we get away with
${.mapfile} ?

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

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

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > Well, if someone wants to see if he can find any problems with this,
> > it would be the patch below...
> 
> 
> Is this really all that is needed? If I understand it correctly, this patch
> simply makes `.' valid character for parameter names. It means, that both foo
> and .bar.foo are put in the same (and the only) table ... both are happily
> listed with `set' ...

As I said: it's the simplest `solution' I saw -- and I really wanted
it only to play with it to see if there are places where parameter
names with dots in it (on the user side, independent of how they are
actually implemented) cause problems.

> what's worse, it makes `foo.bar' hihgly ambiguous. It may
> break scripts that do not expect `.' in parameter names ...

In which way ambiguous?

> I'd expect `.' be treated as names separator - and only in context `.foo.bar'.
> Thus `foo.bar' as identifier remains invalid alltogether (eliminating $foo.bar
> ambiguity). We'll have default namespace for all names without dot and explicit
> namespaces for name starting with dot. All commands should behave just as normal
> Unix :-) - everything starting with dot is "hidden" by default. This should have
> the minimum impact (as long, as users do not request namespaces, they simply do
> not see them at all).

Many questions come to mind, some of them:

- What exactly would we gain by using different tables?
- In which way would they remain `invalid'? Especially from a user's
  point of view -- who should still be able to say `.a.b=c'.
- Are you suggesting new options or new ways of argument handling for
  builtins like set to select a `namespace'? It would be easy to
  `hide' parameter names starting with a dot by just making set/typeset
  not print them -- unless a certain (new) option is given. And
  something similar could be used to make it list only parameters
  starting with `.something' which would give us what I asked
  above. And that without actually using multiple tables, because I
  /think/ that wouldn't be nicely small and easy to implement -- and I 
  still don't see a real advantage of that anyway.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Andrej Borsenkow]

> Well, if someone wants to see if he can find any problems with this,
> it would be the patch below...


Is this really all that is needed? If I understand it correctly, this patch
simply makes `.' valid character for parameter names. It means, that both foo
and .bar.foo are put in the same (and the only) table ... both are happily
listed with `set' ... what's worse, it makes `foo.bar' hihgly ambiguous. It may
break scripts that do not expect `.' in parameter names ...

I'd expect `.' be treated as names separator - and only in context `.foo.bar'.
Thus `foo.bar' as identifier remains invalid alltogether (eliminating $foo.bar
ambiguity). We'll have default namespace for all names without dot and explicit
namespaces for name starting with dot. All commands should behave just as normal
Unix :-) - everything starting with dot is "hidden" by default. This should have
the minimum impact (as long, as users do not request namespaces, they simply do
not see them at all).

/andrej