On Aug 27, 2009, at 11:14 , Konovalov, Vadim (Vadim)** CTR ** wrote:
Here the first/last values appear at the end. The second argument
appears to be the Tcl interpreter (from Tcl.pm). The third
argument is
some sort of blessed reference to the subroutine being called,
although
the stringification is unusual. I have no idea why there's a leading
undef value, or what it's supposed to be a placeholder for. The
documentation only states that you can pass a CODE reference to a
callback. It says nothing about what the arguments are.
Right. The 3 first arguments are basically junk. Functions passed
this way should really start out with doing a splice(@_, 0, 3) :-(
Indeed.
IMO the design of this dates back to Malcolm Beattie's implementation.
My preference would be to change this interface so that the 3 first
args were always chopped. That would make passing [\&foo] and \&foo
have exactly the same behaviour. The best way to fix this would
actually be on the Tcl.pm side, but if this isn't acceptable
Tkx could
always preprocess the arguments it pass to rewrite \&foo into
[\&foo]. I would not document this until we figured out how/if we
want to fix this.
this will break existing code.
Potentially, but code that relies on the specific arguments passed
back is relying on undocumented behaviour. We should not feel too bad
about improving undocumented interfaces.
But IMO that's acceptable, because, as it seems to me, no-one really
used such callbacks in real life.
I would also think that would be rare. If there exist code that does
this and which need to work with any version of Tcl they can probably
use something like:
splice(@_, 0, 3) if @_ >= 3 && ref($_[1]) eq "Tcl"; # legacy crap
my($x, $y) = @_;
Changing this will require some sort of sycnhronization between the
dependant modules (namely Tcl::Tk and Tkx).
I don't think this will be an issue for Tkx by itself. There is
nowhere it relies on such callbacks. There might be Tkx based
applications that are affected.
--Gisle