The question is what ns_proc will do if i give wrong type? Catching all ns_proc calls for exceptions will make code not very clear? How typechecks will be enforced?
-------- Original Message -------- To: naviserver-devel@lists.sourceforge.net From: Zoran Vasiljevic <[EMAIL PROTECTED]> Subject: Re: [Re: Re: [naviserver-devel] ns_parseargs example] Am 30.05.2005 um 12:23 schrieb Stephen Deasey: > > 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. > Another try (I can't just let go) ... I do not see much sense in trying to keep the Tcl argument list format under all costs. Give me a good reason why we should do that? Anyways, we are about to define a new "proc"-type of command (ns_proc) aren't we? What is the sense then to force ourselves to the old format? Why don't we *extend* Tcl-proc arg-treatment like this: {name typecheck ?default_value?} This is *not* Tcl-proc compatible but *is* in the spirit of the language. The "typecheck" above can/will be definitely a list of one or more elements, depending on the check itself. The typecheck is *forced*. You must give a type. If you need no checking at all use "string" which will cover all possiblities. By *forcing* the type-check, many of the programming errors and double-checks in the procedure itself can be saved. Also, all people needing no extra checking can always use plain Tcl-proc calls. Others who'd need checking would use exteneded ns_proc syntax. This is pretty clear and I see no problems with that at all. For example: ns_parseargs {{-retries int 0} {-blockcopy flag} {device string} args} or ns_proc dosomething {{-retries int 0} {-blockcopy flag} {device string}} { # ... } The most natural Tcl-way is to use lists. We've seen that the desperate try to keep the Tcl-proc syntax leads to too complicated nested lists which humans are not easily assembling. So, this is a plain list which is easy to write and read by humans. We can evolve typecheck over time to include more elaborate tests, but a handful of those (string, int, flag, bool, list) are most useful and complete for about all the needs I can think of at the moment. What is wrong with that (except that it perhaps does not follow openacs model)? 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