Re: [TCLCORE] TIP #320: Improved Variable Handling in the Core Object System

[Gustaf N. <ne...@wu...>]

Will Duquette schrieb:
> On Jun 15, 2008, at 7:46 AM, Donal K. Fellows wrote:
>   
>> The only variables automatically brought into a method are those that
>> are declared at the same level (i.e. in the same class/object) as the
>> method. This should mean that if a superclass increases the set of
>> variables it declares, there will only be a problem if the parent
>>     
what is exactly the "parent"? do you mean "superclass"?
>> declares a variable that a subclass was previously declaring (and
>> they're used inconsistently). 
How does this fit together with the first sentence? If certain
instance variables are declared to be autoimported by a class C,
and the meaning is that only the methods defined by the
class C are autoimporting these variables,
what are the problems with some subclass of C?

In general this feature has much potential for confusion since it breaks
locality and makes therefore maintenance more complex.
Also global variables are namespaced variables are explicitly
imported into a proc scope via commands.
The scoping of variables (proc scope, global, namespace,
instance variable) in a single method should be clear just by looking
at this method, not by searching around for potential places.
This form of autoimporting makes refactoring of code more
complex, and can easily lead to surpises for a dynamic class
systems. I am as well not sure, what the intended semantics for
e.g. filters are.

i certainly agree that autoimporting variables is conveniant,
but this can be trivially implemented on the scripting level
by overloading the method "method" (see the various
itcl in xotcl implementations), there is no evident need
for language support.

A different and safer approach would be to use
naming conventions for instance variables (like
in Ruby: variables with names starting with @
are  instance variables). This could be achieved
in Tcl via a variable resolver.
> In the long run, though, I think we're going to need to do better.  As  
> an author of libraries, it really bugs me that a change to my library  
> can break my user's code in perplexing ways.
>   
exactly.

-gustaf neumann