Am 30.05.2005 um 12:23 schrieb Stephen Deasey:
On 5/28/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Well, the above example is wrong. It should be:
ns_proc connect {{{-eightbit flag}} {{-speed list ...
Nested lists are clearly unusable.
They are, indeed, but this is the price for being flexible.
I'm afraid we do not have very much options about all that.
Either we drop the type checking and therefore accept no
flag-type arguments or similar, or we do something like above
and be faced with more complex writing.
The other option is -eightbit:flag syntax. It's not perfect, but it's
better than nested lists and has ~5 years of usage in the ACS behind
it.
Hm... what I do not like about that is: this is a usage convention
and this convention is against the syntax of the language.
Maybe this "against" is too harsh word for it, but still...
As I said many times before, I think that we are going little bit
too far with that. If we just accept the status-quo then we'd have
to live without optional flags (and other types of checking),
that is, one should/could use:
ns_parseargs {{-option true} args}
and write like this:
-option true
-option 1
-option yes
-option no
etc
and internally typecheck: [string is boolean $option].
Nothing will prevent somebody to "-option foo" but
this is then in the responsibility of the programmer.
Since Tcl does not enforce type-checking, we should not do
this either, if it can't coexist peacefully with the language-syntax.
Personally, I'd have nothing against if you add this type of
parsing but I believe I will not be able to use it. If you
think this is widely accepted (I have no such experience so far)
then go ahead; I won't stay in the way.
Cheer's
Zoran
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-
q22005
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
