On 18.09.2006, at 23:03, Stephen Deasey wrote:
I mean that
Ns_ProxyGet()
might be appropriate for C programmers, but that doesn't mean that
ns_proxy get
is for Tcl programmers. It's not just about level of difficulty
either. Mapping the low level C APIs directly seems to add a lot of
difficulty, because you have to take account of the Tcl environment
and all the crazy things that you just don't allow in the C API.
Aha. Well, in that particular case, the [ns_proxy get] is not bad at
all!
You get the handle of "something" that you use to do all kinds of
things.
Later on, when you're done with it, you [ns_proxy put] itback, allowing
others to use the same "something"
How would you make this in a "Tcl way"?
After all, you [open] the channel, then you [puts] to it and then
[close] it. What is not OK here?
I think I know where are you heading and I can understand the idea
but this particular example may not be optimal.
I believe you are thinking about something like this:
ns_mutex lock $lock
do bla bla bla
ns_mutex unlock $lock
The "optimal" way to do that would really be:
ns_mutex lock $lock {
do bla bla bla
}
as it will save you the trouble if "do bla bla" throws error.
In the latter case you must ugly things like
ns_mutex lock $lock
if {[catch {do bla bla} err]} {
ns_mutex unlock $lock
error $err
}
ns_mutex unlock $lock
which is just plain rubbish (because of which we had to invent
our own do/catch/finally command)...
I will take more time to answer on your nsproxy email
as this two are really comming close...
