Murr, Florian schrieb:

Yes, you are right, I overload the setter/getter method and expected naively that it just prints the puts-statement and works otherwise unchanged. [Should have read the manual more properly, I guess :-)]

for each parameter a method for getting and setting variables registered. This method is a "instparametercmd" implemented in C, which is very similar to the set method. This can be as well explained with the forwarder, which could be used to implement the *parametercmds

Class C C instforward x %self set %proc

now a method named x is defined, that calls "[self] set x" when issued. eg.

C c1 c1 x 123

here "c1 set x 123" is called, or in the following line "c1 set x" is issued.

puts [c1 x]

This behavior is more or less identical to

Class C C instparametercmd x

or to

Class C -parameter x

therefore, the instparamtercmd is strictly speaking not needed, but predates instforward and is slightly faster, since everything is in C. The parameters do more, since they can be used to provide as well default values which are used during initialization of objects.

anyhow, in all cases a method named "x" is defined. When you define an instproc named x

Class C C instproc x args {...}

you will overwrite the method "x", in a similar manner as you can overwrite any tcl command, e.g proc if args { ...}

Therefore, there is no chance to do a next in these cases, because the class has now the new method (instproc) instead of the c-level implementation we had earlier.

Furthermore "next" works only when methods are shadowed, when a same-named method is defined by a class/object earlier in the precedence order. This can be achieved e.g. via mixins or filters.

therefore, in your example

X instproc y {args} { puts "[self] y '$args'" my instvar y if {[llength $args]} { set y [lindex $args 0] } next }

the "next" is not doing anything useful, you should replace the last line of your instproc by e.g. "return $y", such that .... [x1 y] ... works

hope this explains, how this works...

-gustaf neumann