[TCLCORE] Re: Procedure/Namespace Behaviour

[Paul W. <pau...@sy...>]

Brent Welch wrote:

>  > >
>  > > 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.

It helps in the sense that you can choose a name that is not in use at the time, but
another file may be sourced later which may attempt a declaration that collides with
the name you picked. I suggested a "renameAuto" procedure in my posting of 25th August,
but feel that this still leaves a nagging doubt, because it is not easy to verify
whether the wrapping will cause collisions. At the very least, the style guide should
recommend that the patterns used for automatic names be avoided in regular naming. In
incr-Tcl, the name chosen for an object named with #auto is constructed by gracefully
steping over existing names whether they were derived manually or automatically.
However, if you ask for a explicit name that has already been taken by the automatic
naming mechanism then this is an error. I suspect that a typical incr-Tcl application
will use #auto almost exclusively, so that such collisions are rare. This is not the
case with procedure names, so automatic names would have to be differentiated by more
than the equivalent of adding an incrementing decimal number to the class name -
perhaps my facetious comment above is not so far off!

> 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.

This did not happen with Donal Fellow's original example in his posting of 15th August
- ::A::foo was executed in ::A, and therefore presumably byte-compiled, but when moved
to ::B it picked up the ::B variable.

> 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.

In my posting of 15th August I suggested redeclaring the procedure in another namespace
but wrap it using "namespace code" for execution in the original namespace. I had
expected objections to be raised that "namespace code" has limitations so that it is
not a general solution, but no comments have been made. If it does work generally, then
an implementation would be to make rename between namespaces add this extra step. Still
have the problem of 'C' procedures and built-ins though.

> So now I'm in a quandry.

How about "rename -keepscope" for the closure semantics?


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