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

["muppet" <scott asofyet org>]

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>