Re: [TCLCORE] TIP #278: Fix Variable Name Resolution Quirks

[Andreas K. <and...@ac...>]

>  TIP #278: FIX VARIABLE NAME RESOLUTION QUIRKS
> ===============================================
>  ABSTRACT
> ==========
>
>  This TIP proposes to fix the behaviour for variable name resolution,
>  modelling it on the resolution for namespace names instead of the
>  current command name resolution.
>
>  DEFINITIONS
> =============
>
>      * a variable name is "simple" if it does not contain the character
>        sequence "::".
>
>      * a variable name is "absolute" if it starts with the character
>        sequence "::".
>
>      * a variable name is "relative" if it is neither simple nor
>        absolute: it contains the character sequence "::", but not at its
>        beginning.

Uh. I dislike this definition of 'relative'. In the core a simple variable is
relative as well. I.e 'relative' is just !absolute, no reference to 'simple'.
To me 'simple' is a subset of 'relative', not an entirely different category.

Hm. ... Looking over the rules even with this change I do not see them becoming
simpler, not really. The special handling of simple is still required either way
...


>  Variable name resolution shall proceed as follows:
>
>      * a simple name refers to a local variable if within a proc body,
>        to a variable in the current namespace otherwise.
>
>      * an absolute is always resolved starting at the global namespace.

Nit: ... absolute <name> ...


>  This behaviour hides a few surprises, especially but not only with
>  respect to creative writing.

IMHO we should provide an explicit example of creative writing to demonstrate
how the trap.

> In order to restore some sanity,
>  *variable* has been invented to selectively force the behaviour that
>  this TIP is proposing (in its usage outside of procedure bodies).

>  Note also that, should both this TIP and [TIP #277] be accepted, the
>  code will continue to work as is through a different quirk. In that
>  case, the namespace "::foo::foo" would be created, and the variable
>  "::foo::foo::name" would be getting all the action.

Wrongly so however, and other parts of the code may still use ::foo::name with
all the consequences (new subtle bugs due to the two variables not in sync).

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122