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

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx