Re: RFC: Operation Options API proposal

[Guillaume Emont <gemont igalia com>]

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.

Guij