First login?
Lost password?
 
 
cellml-tools-developers AT lists.cellml.org 
A list for the developers of CellML tools

Text archives Help


[cellml-dev] Creating StringAnnotation objects


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] Creating StringAnnotation objects
  • Date: Wed, 24 Mar 2010 08:55:03 +1300
Lucian Smith wrote:
>>> But... I don't actually want any of that. In fact, the fact that the
>>> annotations are destroyed when the AnnotationSet is destroyed is exactly
>>> the opposite of what I want--I don't want to have to worry about storing
>>> and properly deleting an AnnotationSet; I just want to store some
>>> information on some objects for the lifetime of those objects.
>>>
>>> Are you saying that I *have* to use AnnotationSets, and that
>>> get/setUserData is actually impossible to use directly?
>> You can use getUserData or setUserData without AnnotationSets;
>> annotation sets are designed to make it easier to do annotation.
>> AnnoTools is built entirely on top of the core API; it doesn't do
>> anything you couldn't reimplement yourself, it only makes it easier to
>> do so.
>
> This sounds very reasonable, but then you say:
>
>> You could implement string annotations yourself with getUserData - just
>> implement the StringAnnotation interface yourself, and QueryInterface to
>> it when you get the annotation back to extract the string.
>
> To me, this sounds like you are saying, "If you finish implementing the
> API, then the API will be complete".

getUserData is more general and more basic; the point of UserData is
that the user implements the interface themselves.

>
> Out of the box, the API has these functions called 'getUserData' and
> 'setUserData', and they seem useful. But they use objects called UserData
> which have zero functions or attributes, so that seems less useful. But
> there are subclasses of the UserData class that do indeed have attributes,
> so that seems useful again. One of them hasn't been implemented yet, so
> OK, fair enough. What about the other one, the ObjectAnnotation? How
> would I implement using that in my original code:
>
> nsCOMPtr<cellml_servicesIObjectAnnotation> annotobj;
> rv = annotobj->SetValue(cellmlobj);

UserData is an interface; you can make an XPCOM class to implement that
interface, as well as others. You can then create an instance of your
own custom class, set it using setUserData, and fetch it using getUserData.

>
> wouldn't 'annotobj' be NULL there, too, and the second line would
> therefore still crash?
>
>> Alternatively, why not just use an nsCOMPtr to store the AnnotationSet
>> as a member of your class, and let it get destroyed when your object is
>> destroyed?
>
> Because my objects live in vectors, and therefore get created and
> destroyed all the time, and I don't trust that situation to work with the
> XPCOM memory management any further than I can throw^Wunderstand it, which
> is zero.

It is reference count based; keeping them in vectors should be fine -
just copy from nsCOMPtr to nsCOMPtr (or nsCOMPtr to pointer to nsCOMPtr
if you prefer - once all the nsCOMPtrs go out of scope the reference
count will reach zero and the objects will be deleted).

>
> I think I'm going to give up on this approach and just create a hash with
> CellMLId's and the strings I want to store, but when I saw 'setUserData' I
> thought 'Oh, hey, I can use that' and am sad that it didn't work out.

You could alternatively do that.

Best wishes,
Andrew

>
> -Lucian
> _______________________________________________
> cellml-tools-developers mailing list
> cellml-tools-developers at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-tools-developers



Archive powered by MHonArc 2.6.18.

Top of page