Re: boxed types and copies

[Havoc Pennington <hp redhat com>]

Tim Janik <timj gtk org> writes: 
> fine, following that reasoning, g_signal_emit() does copying unless you
> come up with a proposal of extending g_signal_new() to support
> pass-by-reference for boxed types that copy itself.

Well, there has to be a way to specify whether the args to a signal
are by reference or by value. It's conceptually broken to put this
information in the type. The fact that my value is of type "int" does
not tell me whether it will be passed to functions as "int" or
"int&". It's just not a property of the type. Notably, in C++, once in
the body of the function, parameter "i" declared as "int & i" and "int
i" will have exactly the same type. The way in which the arg is passed
does not change its type for type-checking purposes.

However, I think we could aggressively simplify as GTK 1.2 does, and
simply say that all boxed/object signal args are passed by reference,
because no one ever wants to copy them. Then we don't need to specify
the reference/value property for each signal arg, even though
conceptually signal args do have such a property.

When copies are necessary, they can be performed either just before
emitting the signal, or they can come in the marshaller (for LB when
it makes sense).

Refcounted objects should not ever be boxed anyway; they should be
GObject derivatives, because LB require object data to handle
refcounted objects.

> but that is besides the point, what good are your boxed-copying
> stubs for, if that doesn't actually work for LBs?

The type is a boxed type because it _can_ be copied by value, if you
want those semantics. Just because the type has copy/free operations
doesn't mean it's appropriate to invoke them at every opportunity.
e.g. if a language such as Python has a way to copy by value, then
gtk_text_iter_copy() should be used to implement that.

LB have to have a way to give the programmer a reference to a C
object. i.e. if I'm in a python callback attached to insert_text(), I
need to get a reference to the GtkTextIter. That means that the Python
binding has to be able to create a temporary GtkTextIter wrapper that
doesn't own the GtkTextIter. I don't see any real way around that. How
do you propose implementing this insert_text signal?  Would you add a
new type GTK_TEXT_ITER_BY_REFERENCE? I don't think that will make LB
any easier. And it doesn't make any sense conceptually, because
"BY_REFERENCE" has nothing to do with the type of the object.

Havoc