[gt-users] Attach user data to GtGenomeNodes
Gordon Gremme
gremme at gmail.com
Sat Feb 21 15:04:18 CET 2009
>>> void gt_genome_node_add_user_data(GtGenomeNode *node,
>>> void *key,
>>> void *data,
>>> GtFree free_func);
>>> void *gt_genome_node_get_user_data(const GtGenomeNode *node,
>>> void *key);
>>> void gt_genome_node_release_user_data(GtGenomeNode *node,
>>> void *key);
>> Looks good to me. Would gt_genome_node_release_user_data() also free
>> the user data object?
>
> Yes, that was my idea. The caller is responsible to ref() the object
> first or not give a GtFree callback if he/she does not want this.
>
>>> Do you think we should introduce a free-function for the key as well,
>>> like in the generic hashmap class?
>> I don't think so. We should agree upon a convention on what is used as
>> key. My suggestion would be the constructor method of the user data
>> object.
>
> Wouldn't that force the user to write loads of small container classes
> if he/she wants to attach more than one object of the same class? For
> example, it is not possible this way to add more than one GtStr (with
> gt_str_new constructor) to an object unless something like a
> MyMultiStrContainer class (with a unique constructor method) is created
> to hold multiple GtStr references.
> OTOH, I can't think of a better solution, so I'm ok with this.
>
> I still am unsure how to implement this in the scripting bindings
> though. In the bindings, the C constructors are not public and should
> also not be touched by a user. Also, I have to find out whether
> implementing this on the C side allows a bindings user to create his/her
> own container structures and attach them using the C interface.
For the record: I talked to Sascha fact-to-face about this yesterday
and we agreed to use strings as keys.
It makes things a little bit more brittle on the C-side but it should
greatly simplify the usage in the bindings.
Gordon
More information about the gt-users
mailing list