On Thursday 05 June 2003 07:36 pm, Nathan Folkman wrote:
> We could rename the command to be "ns_evil". :-)
You've got my vote!
Actually ... as currently implemented it would probably be better to just
rename it "ns_synch" or the like.
global foo
set foo bar
ns_eval {}
is equivalent to
ns_eval {
global foo
set foo bar
}
In that both whomp on your entire global space and "foo" is available and set
to "bar" in both cases to other interps.
Just to shortcut you a bit, ns_eval is now in nsd/init.tcl where it calls
_save_namespaces:
proc ns_eval {args} {
set len [llength $args]
if {$len == 0} {
return
} elseif {$len == 1} {
set args [lindex $args 0]
}
set code [catch {uplevel 1 $args} result]
if {$code == 1} {
# TCL_ERROR: Dump this interp to avoid proc pollution.
ns_markfordelete
} else {
# Save this interp's namespaces for others.
_ns_savenamespaces
}
return -code $code $result
}
The old code first evaluated the script to make sure there were no errors then
set things up so other interps would run it ASAP.
I can see why the current approach is used ... there might be any number of
ns_evals run before the next update of an interp is done in the current
scheme. Without immediately evaluating the script in all interps (so it can
be tossed and later replaced by the script attached to later ns_eval calls)
it's hard to see how the old semantics can be maintained.
Maybe it's just a bad idea and people should use nsvs that have proper locking
etc. ns_eval could log a bold warning saying "I'm EVIL don't use me!" and I
wouldn't care :)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
