[Kstars-devel] More (old) thoughts on AuxInfo hash

James Bowlin bowlin at mindspring.com
Thu Jun 11 20:57:23 CEST 2009


On Thu June 11 2009, you wrote:
> On Friday 05 of June 2009 15:19:54 Akarsh Simha wrote:
> > But I have always wanted to have a UUID for every object in
> > KStars. This might be hard stuff, but it would be nice if every
> > object carried a few bytes of its own UUID. Maybe it's not required
> > - except for unnamed stars - where it will be rather useful to have
> > a UID, or even a legitimate catalog number attached.
>
> If we want to separate AuxInfo from SkyObject it's not a good thing
> to do. It rather mandatory.

I disagree, although we might want/need a UUID for other reasons.  For 
example, storing all AuxInfo data in a hash will make it easier to
save (to disk) and restore all the AuxInfo information.

To me, the key thing is that AuxInfo stores user input so the number of 
AuxInfo objects actually used will be small (compared to the number of
unnamed stars, or even the number asteroids).

Here is an easy way to only hash AuxInfo for stars.  The AuxInfo field
in StarObject should be a pointer whose default value is NULL.  For most
objects when an AuxInfo field is to be accessed, the pointer is checked
for NULL.  If it is NULL, we create a new AuxInfo object and fill the 
pointer with its address.

For stars, we do almost the same thing, but when it is time to create a 
new Auxinfo object (because the pointer was NULL) we first check the 
hash to see if an AuxInfo already exists for this star.  If a pointer 
already exists in the hash then we use it, otherwise we create a new 
AuxInfo object and add the pointer to the hash in addition to using it 
to fill the field in the star object.

One benefit of this scheme (in addition to being very simple) is that
we don't need to come up with a UUID for every single object all at 
once. That way we can start hashing AuxInfo for stars ASAP (because 
what we have now is broken IMO) and then take our time to design the 
UUID correctly without feeling pressured.

These ideas were already discussed a year ago.  The earlier discussions
can be found with Google(kstars-devel auxinfo).


-- 
Peace, James


More information about the Kstars-devel mailing list