From: Vlad S. <vl...@cr...> - 2006-04-16 00:56:15
|
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 <vl...@cr...> 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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |