Re: boxed types and copies

[Tim Janik <timj gtk org>]

On 12 Dec 2000, Owen Taylor wrote:

> Tim Janik <timj gtk org> writes:

> > hm, i'm kinda two folded on that issue.
> > 
> > on the one hand, the easy thing to do is to restore gtk_signal_emit(),
> > but then, your signals that use these boxed types are really only
> > usable with gtk_signal_emit() (not g_signal_emit()).
> > beyond that, code that deals with your boxed values will get things wrong,
> > since you copy the structure while you actually want it passed by
> > reference.
> > i think owen has a similar thing with selection data or something...
> > basically, boxed values that aren't usefully copyable, must be reference
> > counted so they can be passed by reference.
> > the reference counting doesn't need to be exposed, you can have static
> > ref/unref and pass that in to g_boxed_type_register_static().
> > 
> > owen, what do you say? boxed types need to be either copy-able or
> > reference counted, otherwise LBs or editors can't pass them around
> > and store them away anyways. doing that static hack for gtk_signal_emit()
> > just defers the problem and makes things work for just this moment in our
> > limited testgtk universe.
> 
> During emissions, the person emitting signal owns the things that it
> is passing into the signal; thus there is no need to make copies of them.

wait a second, first, g_signal_emit() uses GValue generically, apart from
the obvious reasons of being able to deal with data generically, GValue
makes sure that a reference count on its contents is being held while
it exists. that boxed types sometimes copy themselves instead of reference
counting themselves is a different issue, and more of an implementation detail
of certain boxed types.
the problem is that copying doesn't go along with "here's data, modify it
and get it back to me" which is how havoc intends the text iterator to work.

> gtk_widget_size_request() needs to pass in the GtkRequisition by value, and 
> not make a copy.

..by reference you mean.

> Also GtkRequisition should not be GTK_TYPE_POINTER since it needs to be 
> useable from language bindings?
> 
> Does GtkRequition thus have to be ref-counted?
> 
> Whether an object is ref-counted or copied by value should not determine
> whether it is possible to pass it in by reference via a GValue.

"should not" is the right phrase here, since our current system does
provide you with either
- pass by reference -> have refcounting ability
  this allowes for back-propagation of modifications of the data
or
- pass by value -> be copyable
  this does not allow for back-propagation of data modifications

what i'm trying to point out here, is that we need to
1) follow given limitations, i.e. do refcounting if you want
   back-propagation of modifications
or
2) extend what we have to deal with pass by value + back-propagation


> 
> Regards,
>                                                 Owen
> 

---
ciaoTJ