RE: [Xotcl] Is this a bug?

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Tue, 13 Dec 2005 12:08:24 +0100

Thanks a lot for your thorough explanation!

I tend to think in "invariants" and I memorized that having a method
specialized this way

    C instproc someMethod {args} { next }

 should leave my program invariant with respect to functionality.

But this obviously has the exception of getter/setter methods.

Regards,
 - Florian

-----Original Message-----
From: Gustaf Neumann [mailto:neumann_at_wu-wien.ac.at]
Sent: Thursday, December 08, 2005 4:15 PM
To: Murr, Florian
Cc: xotcl_at_alice.wu-wien.ac.at
Subject: Re: [Xotcl] Is this a bug?

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