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

Reply via email to