Re: RFC: Operation Options API proposal

[Iago Toral Quiroga <itoral igalia com>]

El mar, 29-03-2011 a las 13:15 +0200, Guillaume Emont escribió:
> On 29/03/2011 13:02, Iago Toral Quiroga wrote:
> > El mar, 29-03-2011 a las 12:33 +0200, Guillaume Emont escribió:
> >> On 29/03/2011 10:47, Juan A. Suárez Romero wrote:
> >>> On Fri, 2011-03-25 at 11:33 +0100, Iago Toral Quiroga wrote:
> >>>>>> I think the proposal is good. I would start the implementation and
> >>>> then,
> >>>>>> if we find issues we may need to adjust some bits.
> >>>>> Before starting, I think we need to ensure we agree on a few more
> >>>> points:
> >>>>>  - inherit from GrlData? (I'd say yes)
> >>>>
> >>>> I would not like to inherit from GrlData, same reason I always give
> >>>> for
> >>>> that. GrlData was designed to support very different semantics (those
> >>>> of
> >>>> the content hierarchy: GrlMedia, etc) and here we would be using it
> >>>> for
> >>>> a concept that is semantically different (the operation caps and
> >>>> options). If we want to reuse GrlData I'd rather use composition than
> >>>> inheritance, but even in that case I'd probably just use a GHashTable
> >>>> and leave GrlData alone. 
> >>>
> >>>
> >>> I guess that Guillaume already went with GHashTable, but to give more
> >>> feedback in order to understand if GrlData fits or not (besides the
> >>> semantic reasons Iago gave above):
> >>>
> >>> * In GrlData, the key must be a GrlKey, and must be registered on the
> >>> plugin registry.
> >>>
> >>> * GrlData is designed to work with multi-valued elements.
> >>>
> >>> Pretty sure the kind of data to be stored in the caps/options are not
> >>> the one that GrlData handles.
> >>>
> >>> In fact, all those reasons were the ones that made me forget about using
> >>> GrlData to implement GrlConfig.
> >>
> >> Actually, I'm trying to go with GData in the end, mainly for semantic
> >> reasons:
> >>  - GrlData needs registered keys, and we don't want to mix data keys and
> >> caps or options keys
> >>  - GHashTable is meant for a dictionary of (key, value) where key is of
> >> a given type and value is of a given type (the value destroy func you
> >> give to g_hash_table_new_full() is for all values), which means all
> >> values need to be of the same type, meaning we would have to use GValues
> >> which I find a bit heavy to program with
> >>  - GData is meant for a dictionary of (key, value) where key is a string
> >> (or, well, a GQuark made out of it), and value is of any type, with a
> >> destroy function given individually for each valye. I think this fits
> >> more the type-wise heterogeneous data we want to store.
> >>
> >> If at some point experience shows GData is too slow (it's implemented
> >> with a linked list), we can still switch to GHashTable + GValue, but
> >> that would make the code a bit more complicated, especially since the
> >> stuff we would store would need to be GType registered (or use GBoxed).
> >> Just passing the value and a destructor sounds much simpler to me.
> > 
> > I think the risk with this approach is not performance but semantics.
> > The problem that GrlData tries to solve is not the same we try to solve
> > with GrlOptions or GrlCaps. GrlData is there to solve the needs of the
> > content hierarchy (GrlMedia, GrlAudio, etc) and it may need to be
> > changed in the future to fit those needs, rendering it not so useful for
> > the case of GrlOptions or GrlCaps any more.
> 
> I agree with you on the semantic issues with GrlData, that is why I was
> talking about using GData[1] (with two letters less, from GLib), which
> seems to have the right semantics, but might not be as efficient as a
> GHashTable.

This is twice I have misread an email of yours, gotta be more careful in
the future, sorry again O:)

Iago