Tcl bytecode and namespaces

0
votes

As far as I understand Tcl bytecode is being invalidated if the namespace of the caller is different from the namespace of the original. So far so good. the tricky problem which I do not understand completely is how it works with procs.

If I have a proc in global namespace and I call it from a specific namespace will the bytecode of the proc will be under the specific namespace of the global namespace? Will the bytecode of the specific namespace will be invalidated due to calling proc from a different namespace?

If the proc is in a specific, but a different namespace than the caller will it change the answer?

What happens when we call a proc from a different proc?

Does upvar 1 in proc will work when it has to link to a variable from a different namespace?

Thanks very much in advance.

1
namespacestclbytecode

1 Answers

0
votes

A call of a procedure from another namespace does not invalidate the bytecode for that procedure. The current namespace is the namespace of the procedure when the procedure is running, and that is a different namespace from the namespace of the calling stack frame.

Using the rename command to move a procedure from one namespace to another — a rare operation in production code — will usually invalidate the bytecode. (The issue is that different namespaces may resolve the command names to different things, and that may in turn mean that the correct bytecode sequence is different.)

TclOO methods work differently, though the fact in my first paragraph — that the current namespace in one stack frame is not necessarily the current namespace in the caller stack frame, and that that never invalidates the bytecode — continues to apply.

If you have a build of Tcl with the debugging option compile defined, you can set the special global tcl_traceCompile to 1 to get a bit of debugging information printed on every compile. (You get detailed information by setting it to 2, but the tcl::unsupported::disassemble command is a much more convenient way of doing that.) That may help you understand when compilations are actually done; Tcl tries to avoid recompiling things even though its compiler is fairly fast.