[TCLCORE] Re: Procedure/Namespace Behaviour

[Brent W. <we...@aj...>]

>>>Paul Welton said:
 > George Howlett wrote:
 > 
 > > In message <200...@po...>, Brent Welch writes:
 > >
 > >  : The other use of rename - call it "rename without behavior change" -
 > >  : is easy to justify.  That has been used for code profiling, and for
 > >  : enhancing commands by intercepting them, doing something, then
 > >  : calling the original procedure.
 > >
 > > I can do all this now in the same namespace.  Why a different
 > > namespace?
 > >
 > > --gah
 > 
 > Because if I am intercepting a procedure in a namespace that I am not responsible
 > for, I cannot choose a name with total confidence that it will
 > not collide with an existing name or one that may be used in future. Of course if
 > you choose an identifier including your own name and social
 > security number then you are reasonably safe, but I would not like to see the
 > style guide advising this :)

[info command] will help you pick a name that does not collide.

I'd like to bring a new perspective from my friend David Nichols who is
very smart.  When I explained the issue (he used Tcl long before
namespaces, now is a heavy Java user) he instantly understood the two
possible semantics and the various problems.  He said something like this:

"Well, it seems like you'd want closure semantics where you bind the
command to its original namespace.  But, that is very suprising to people.
The only reasonable thing to do is disallow it because both semantics 
have problems.  Futhermore, what happens when you
append a couple lines to the procedure definition and have to recompile,
won't you have to be careful you don't bind to the new namespace."

I think this last point touches on the reasons for the current semantics.
You are unlikely to change the definition of the procedure, but there is
a ordering problem between the rename and when you bytecode compile the command.
If you do the rename before the procedure has been executed, then Tcl
would end up compiling in the context of the new namespace.  However, if
the procedure was executed once first, it would have been compiled in
the context of the original namespace.  So, you have to do something
special or you get different results depending on if the procedure
had been compiled already or not.  I think the easy solution was to
toss the bytecodes at the time of rename, so Tcl would "naturally"
compile the procedure in the context of the new namespace.

So now I'm in a quandry.  I don't understand how the current semantics
can be safely used, and it looks like getting closure semantics
will be harder than might be expected.  I wouldn't be offended if
rename space1::foo spacde2::foo
raised an error.  I'm also still waiting for a compelling example
where renaming between namespaces is used for something other than
hiding the old name.

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com

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