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

[Bjarne Steinsbø <bosteins broadpark no>]

muppet wrote:

> the extra questions arise in figuring out how to handle the marshalling
> of this rather non-standard signal: you are (apparently) allowed to edit
> the text in the string passed to insert-text, and you are supposed to
> write through the position pointer.  what's a proper way to handle this
> in perl?
>
> in perl subroutines, @_ is passed by reference, and modifying a value in
> @_ modifies the caller's version of it.  the idiom my (@params) = @_; is
> a way to emulate pass-by-value.
>
> in light of this, my custom marshaller gives you the values passed in,
> and the retrieves the values again after calling the subroutine, and
> puts those back in the marshalled values.  since the marshaller gets a
> GValue containing the string instead of just a pointer, this means we
> can actually alter the length of the string, as well.
>
> also, string lengths are useless in perl, so the third argument to the
> handler is pointless.  thus, my marshaller *changes* *the* *call*
> *signature* of the signal to remove that unused parameter.
>  
My 2 cents' worth of opinion is that the "best" way to signal a 
changable string to a perl sub is to give the sub a reference to it.   
Input params by value (even if they are simulated), output params 
returned, and in/out params by reference.  (Sure, we all use the trick 
of changing @_ from time to time, but at least to me that's a left-over 
habit from good'ole' perl4 days, when we had no proper references, and 
changing @_ was at least as clean as working through the symbol table 
and passing the variable name.)

The string length isn't needed, but does it hurt?  Enough that you want 
users to remember this one exception and spend time documenting it?

Bjarne