Re: TIP 278: does it cause any breakage?

On 11 Oct 2006 09:41:34 -0700,
"miguel sofer" <miguel.sofer@xxxxxxxxx> wrote:

Please refer to the tip text: http://tip.tcl.tk/278

I am trying to establish how much breakage this TIP is likely to
cause. All testing is welcome. Please bang on it, and provide
feedback.

I have thus far pretty much avoided namespaces totally, for two
main reasons:

One, is the (IMHO "bizzare") behaviour you're referring to. If I do a
[set x], it should work on the variable "x" in the current scope, not
go wondering off elsewhere. Period. I shouldn't have to do a [catch
unset] first, on every single variable I wish to set in the current
namespace, and it should work the same as it does for procedures.
(I feel that automagically reaching back to global, or anywhere other
than the current scope, should ONLY happen when actually invoking a
command.) We have [global] and [variable] commands for use in proc's,
which IMHO, sets up the expectation that variables don't exist unless
we bring them into our current scope. That expectation holds true in
the case of a proc body, but fails in the case of a [namespace eval],
which is just odd.

The other (at least workable) reason I've thus far avoided namespaces,
though, is that it's easier to reference a variable in the global
namespace, than it is to reference one in the "current" (or "previous")
namespace. For one thing, [variable] ISN'T analogous to [global]. I've
never found a use for [variable]'s ability to set the value, all its
ever done for me, is to force me to either use one [variable] per
variable, or use a combination of [upvar 0] and [namespace current]
(which gets rather ugly).

I'd love to see [upvar] get the ability to take a namespace instead of
a level, it would make this whole issue a whole lot clearer. Would it
make sense to have the empty string refer to the current namespace,
since :: already refers to the global one, and the current level is
already a zero? Referring to a child namespace with a name that looks
like a level identifier can be easily achieved by way of [namespace
current]. And I know you can already use [upvar 0] and then slap a
namespace prefix on every variable you want to import, but that's just
ugly.

I'd also love to see [variable] lose its ability to set the value of a
variable (an option, perhaps?), or at the very least, take on proc
argument list like semantics. Better still, introduce two new
commands. One for fetching a list of variables from somewhere (same
as the enhanced [upvar], but simply retaining the variables original
name). And one for setting the value of a bunch of variables that don't
exist, with an optional indication of WHERE the value should be set;
default would be where it came from ([variable]'s current semantics),
but you could also tell it to use the current scope (it still doesn't
exist outside of this procedure), or the global namespace (pending the
passing of this TIP).


For my own needs, I've actually implemented an [nsvar] command that
takes the usual [upvar] level indicator, and does an [uplevel $level
namespace current] to obtain the namespace to use in an [uplevel upvar
0]. But it's messy, ugly, and sometimes a little confusing. (It also
needs to use [uplevel 1 [uplevel $level]] to avoid having to manipulate
the level specifier. I wonder if upvar/uplevel could take a -n
adjustment like [lindex] and its ilk?) Allowing [upvar] to fetch its
variables from anywhere, I'd think, is much less surprising.


Summary of my whims herein (in order of interest):
- Minimum cases of automagical resolving of anything. (this TIP)
- [upvar] with a namespace as "level" argument.
- [variable] as a truer counter-part of [global]. (or see next)
- A new [global]-styled counterpart to [upvar]
- [upvar] with a level adjustment ala [lindex ... end-1]

That, I think, would make namespaces far more friendly.


Fredderic
.

Relevant Pages

  • Re: "namespace upvar" question
    ... "namespace upvar" would redefine the link of that variable a, ... proc printVarType {varNames locals globals} { ... set globalVar "global variable"; ...
    (comp.lang.tcl)
  • Re: TIP 278: does it cause any breakage?
    ... takes the usual level indicator, ... namespace current] to obtain the namespace to use in an [uplevel upvar ...
    (comp.lang.tcl)
  • Re: why upvar is a sledgehammer
    ... Donal K. Fellows wrote: ... upvar 0 state::$this ... should always be a colon-free name. ... Uwe's should however not work for a different reason: you cannot upvar a namespace var to a proc-local variable: ...
    (comp.lang.tcl)
  • Re: why upvar is a sledgehammer
    ... Uwe Klein wrote: ... bad variable name "::x": upvar won't create namespace variable that refers to procedure variable ...
    (comp.lang.tcl)
  • Re: Scope and program structure problems
    ... then I'd be declaring the variables/objects explicitly ... I personnally find the assignment, import, class and def statements (all having a binding behaviour) to be rather explicit. ... their scope according to how/where they were declared. ... Names bound within a class statement lives in the class's namespace ...
    (comp.lang.python)