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: lpsmith at spod-central.org (Lucian Smith)
  • Subject: [cellml-dev] Creating StringAnnotation objects
  • Date: Tue, 23 Mar 2010 22:37:02 +0000
* Andrew Miller <ak.miller at auckland.ac.nz> [2010-03-23 19:55] writes:
> Lucian Smith wrote:
> >
> >>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.

OK, I guess I can buy that, but I'm pretty sure that nobody will ever take
you up on your offer, for the simple reason that the API is not
contributing anything here. In fact, by providing an interface and no
implementation, it's actually taking options *away* from the user. "You
have to do everything yourself, and additionally, you have to make it
conform to these specifications." Why would anyone ever do that? If I
need to implement something myself, I'm going to do it in a way that best
suits my individual program.

But I guess the actual implementation is the AnnotationTools thingummy,
so, OK. This all needs to go into the documentation, of course, but I
realize the documentation is a work in progress.


> >>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).

It is still conceptually weird to me that I can't store the annotation of
an object on that object, but OK.

Similarly, if I re-use an nsCOMPtr, will the reference count of the thing
it used to point to drop appropriately?

-Lucian


Archive powered by MHonArc 2.6.18.

Top of page