Yes, it is more convenience but even nsv_ shared variables work the same
way, keep stringified values and objectifies on the return.
We decided to get rid of thread specific caches and keep global ones
only, and at that time i was for it but now i think simple thread local
cache should be in the core to offer more flexibility to the developer.
But i am not insisting.
Stephen Deasey wrote:
On 4/14/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Yes, i always use Tcl vars but when i have too many different callbacks
and filters, using simple mechanism to access named value that is global
inside the thread make it easier than performing multiple global
statements over the code. If i want to add another var, i need to create
Tcl wrapper so i do not need to go over the code and see where i may use
it, so in this case ns_tls will make it easier. But in general, global
Tcl var is way to go.
If the main motivation is convenience, can't you just write some
simple Tcl wrapper around global arrays? A disadvantage of the way
you have it now is that everything is stringified before it's stored
in the set, and re-objectified on the way out.
This is a pretty specialised function. I don't think the core is the
right place for it.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
naviserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
