[Reposted - Original message sent only via email by mistake]

Gisle Aas wrote:
> Michael Carman wrote:
>>
>>  $text->configure(-yscrollcommand => [$scrollbar, 'set']);
>
> The effect of the statement above is the same as if you did:
>
>   $text->configure(-yscrollcommand => "$scrollbar set");
>
> When the callback happens it's all handled on the Tcl side of things.

Would that work? Is that a *fourth* possible syntax?

>>  $text->configure(-yscrollcommand => [\&_set, 'foo']);
>
> It's behaviour inherited from Tcl.pm's call function, but it's
> not really documented there either. This form is treated the
> same as:
>
>    -yscrollcommand => [\&_set, Tkx:Ev(), 'foo']

Yeah, the positional dependence of Tkx::Ev() stumped me until I found it
in the docs. I still find it irksome but I imagine that it's due to a
technical limitation.

> Which brings up the question what order args appear in if you provide
> stuff in Tkx::Ev() to be expanded. I think the order is:
>
>    1. arguments that the command/function is called with from the tcl side
>    2. the expanded Tkx::Ev() args
>    3. the rest of the values from the perl array as passed
>
> The documentation should be enhanced to explain this.

Thank you! This is a major gap, IMHO. Are there ever any cases in which
either Tcl or Tkx::Ev() could return a variable number of things? If so,
that could be problematic.

>> The weirdest case is this one:
>>
>>  $text->configure(-yscrollcommand => \&_set);
>>
>> If I dump @_ in _set() I get this:
>>
>>  $VAR1 = [
>>    undef,
>>    bless( do{\(my $o = 58361464)}, 'Tcl' ),
>>    '::perl::CODE(0x37c7cdc)',
>>    '0',
>>    '1'
>>  ];
>
> The 3 first arguments are basically junk. [...] 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

I fully agree. The reference to the Tcl interpreter is the only thing
that seems like it might be useful and even that's doubtful. Is there
anything that either depends on the current behavior or works around it
by ignoring the cruft?

> Hope this clarifies things.
>
> If you want to help out by enhancing the documentation consider
> cloning <http://github.com/gisle/tkx/>.  I'm also happy to give you
> direct 'push' access to this repo if you want.

Yes, that's very helpful. I'll try to work up a doc patch. As for
cloning vs. direct access I'll do whatever you'd prefer. I haven't used
git before so this will give me an excuse to play with it. Maybe I'll be
able to figure out if Linus is right that anything based on CVS is
fundamentally flawed. ;)

-mjc

Reply via email to