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

[Donal K. F. <don...@ma...>]

Gustaf Neumann wrote:
> Will Duquette schrieb:
>> 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"?

Bah. I must have been tireder than I thought when writing that. Yes, I
mean "superclass" there.

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

There are several issues here. Whether to do magical variable renaming,
and how many variables to automatically make available (the mechanism
for implementing this is a separate matter).

Let's be frank here: I don't like fancy variable naming schemes. They
are better than maintaining separate tables of variables for each class
that an object is an instance of, but that's not to say that I'm in
favour of either. I like keeping the internal model of variables close
to the model seen at the scripted level. (I want to allow a subclass and
a superclass to refer to the same variable if they desire; variable
renaming would make that difficult without lots of extra machinery.)

The other thing I don't want to do is to make all instance variables
automatically visible in all methods invokable on that instance. That's
clearly a maintenance problem. But the status quo (nothing available) is
perhaps not that great either.

The way forward has to be explicit declaration somewhere, and a
class-level declaration of variables seems reasonable and an automatic
availability of the variables in methods at the same level (i.e. that
are normally in reasonably close proximity to the variable declarations)
gets a fair balance between various forms of maintainability. Subclasses
that want automatic access to the same variables will have to say so for
themselves (i.e. the variable lists aren't inherited, and can't be
because that would take us back into the known-problematic all-visible
case).

> In general this feature has much potential for confusion since it breaks
> locality and makes therefore maintenance more complex.

"Breaks locality"? Either you've misread the TIP (could be; it's a first
draft, not a final version) or you're arguing for stronger isolation
than I think is Tcl-ish. (See my comments above about naming schemes.)

Actually, I hope it's the isolation argument. That's by far the most
interesting one. :-D

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

That's the status quo. My impression (from discussion on this list) was
that that was unacceptable.

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

1. Filters are entirely orthogonal.
2. A dynamically-generated class need not use this mechanism at all.

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

This argues for variables that cannot be shared between classes, even
when that is desired. It also makes things "interesting" when it comes
to working with variables in objects with other parts of Tcl/Tk.

For example, consider a megawidget system where you've got an entry
class and spinbox and combobox subclasses. Which variable does the
spinbox's value get linked to; the one declared by the entry or the one
declared by the spinbox? (Tk won't do both.)

Donal.