[TCLCORE] Procedure/Namespace Behaviour

[Donal K. F. <fel...@cs...>]

Is there any good reason for the behaviour of test proc-3.4 in the
test suite?  (I include it here for quick reference.)

  test proc-3.4 {TclObjInterpProc, procs execute in the namespace in which they were defined unless renamed into new namespace} {
      catch {eval namespace delete [namespace children :: test_ns_*]}
      catch {rename p ""}
      namespace eval test_ns_1::baz {
          proc p {} {return "p in [namespace current]"}
          rename ::test_ns_1::baz::p ::p
          list [p] [namespace which p]
      }
  } {{p in ::} ::p}

The problem with this comes when you are working with various systems
(in pure Tcl) each of which wants to overload the [exit] command to
give them a chance to clean things up nicely; if there is only ever
going to be a single procedure installed over [exit] then there is no
problem as you can simply rename the old exit into a private namespace
out of the way and create the new version, which knows the private
name and calls it at the end of its execution, in its place.  However,
while this technique is effective for a single such replacement, it
fails horribly when several software modules want to do the same
thing, since the second module to install itself moves the first
module's exit handler into a different namespace, which can change the
behaviour of the system in difficult to predict ways (e.g. if the
second system has a [close] command defined in it...)

If there is a good reason for the existing behaviour, I'd love to know
it.  If not, I think it ought to be changed so that procedures always
execute in the namespace where their command existed initially, i.e.
[rename] doesn't modify the context that a procedure executes in.

Ideas?  Brickbats?

Donal.
-- 
Donal K. Fellows, Department of Computer Science, University of Manchester, UK.
(work) fel...@cs...     Tel: +44-161-275-6137  (preferred email addr.)
(home) do...@ug...  Tel: +44-1274-401017   Mobile: +44-7957-298955
http://www.cs.man.ac.uk/~fellowsd/  (Don't quote my .sig; I've seen it before!)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.