Re: Reading completion manual

[Bruce Stephens <B.Stephens@xxxxxxxxx>]

"Andrej Borsenkow" <borsenkow.msk@xxxxxx> writes:

>  - use new option character (do we have one free?)
>  - implement long options
>  - (really wild one) implement name spaces.
> 
> I'd like the last one, but it is probably impossible. A command name
> may have any character, so there is simply no char that can be
> (safely) used as delimiter. So, long options is probably the only
> viable solution. And quite useful in other places as well.

I thought namespaces had been discussed before?  What's the objection
to allowing "." in variable names, and regarding it as a component
delimiter in function/command names?  Hmm, this isn't a good idea; I
quite often use things like "cp $i $i.bak" and stuff.  I wonder how
ksh93 copes with this?  Maybe you have to predeclare name
spaces---that would be acceptable and sufficient, I should think.

I seem to remember that ksh93 supports this kind of use, and the
defines a number of special components which, if set, change the way
that variable assignment and things get done.  

(So if you have a function foo.WRITE, then that gets called when you
try to write to foo.  Something like that, anyway.  A better interface
might be to copy the Perl tie ideas---allowing special associative
arrays and things as Bart suggested; you wouldn't need name spaces for
this, of course.)