Re: RFC: api change for insert-text (Re: Bug report for signal "insert-text")

Torsten Schoenfeld said:
On Wed, 2003-11-05 at 16:00, muppet wrote:
i have it fixed, but i would like everyone's comments on the fix before
i commit it.  don't let the talk of marshalling and C data types scare
you, the real thing i need comments on is the fact that i want to watch
for changes in argument values for this signal and change the its call
signature (removing a parameter).

I don't see any way to solve this and not break the API, either. But did
you consider using return values for those modifiable values?

in fact, that was the first way i went about doing it.

the annoying part of that is "why do i have to return these two values if i
don't want to modify them?"

at some point in this morning's snooze-button-snooze-button-shower stupor, it
seemed like a grand idea to look for the values to be returned from the
callback, and if they are not returned, refresh the values from the arg stack
--- essentially using both methods.  this is indeed the most Perlish way,
because TIMTOWTDI.  :-)

on the technical side, i also considered adding some whiz-bang features to
GPerlClosure to support this mode of operation in order to remove copied code
and the manu opportunities to screw up.  e.g., install a custom marshaller, in
that marshaller set flags in the closure, then pass the buck to
gperl_closure_inout_marshal(), which has the logic for the inout handling. 
this logic would not be in the standard marshaller, mind you, to avoid the
associated performance hit.

(by the way, i really like your example. =)

That seems more Perlish to me. I didn't look into implementing this in
XS, so there may of course be technical reasons that'd render this
solution impossible.

nothing technical makes it impossible -- there is already code in a couple of
places that works this way with GPerlCallback.

muppet <scott at asofyet dot org>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]