Re: [coldsync-hackers] New Perl question; Do I need to keep both a hash and an array?

[Christophe Beauregard <christophe dot beauregard at sympatico.ca>]

On Tuesday 10 June 2003 00:23, Izzy Blacklock wrote:

> It seems to be working fine.  Is there an advantage to the exists
> function?

Yes, especially if you don't need the value.

my %hash;
$hash{$id} = 0;

exists $hash{$id} evaluates to true.
$hash{$id}, however, is false.

If you're storing, say, array indices as hash values (or anything else where 
zero or an empty string is a legit value) exists is the only way to test 
for hash membership.

Also, exists has no side effects. For any hash, $hash{'random text'} causes 
the entry $hash{'random text'} to be added to the hash with an undefined 
value. This will create problems should you, say, call keys on it.
exists $hash{'random text'} will never cause the entry to be created if it 
wasn't already there.

> Am I likely to trigger a bug by not using it?

The way you're using it now, probably not. But you definitely want to get 
into the habit before you start writing stuff where it _will_ bite you in 
the ass.

> >   my @nhSorted =
> >     sort { $NamesHash{$a} <=> $NamesHash{$b} } (keys %NamesHash);
>
> This is what I was missing! :)  This technique may come in handy for
> something else one day, but I don't think it provides any advantage for
> my current problem.  This method delays the need to reserve memory for
> the array up front, at the expense of needing extra CPU time to generate
> it later.  In the end, I still end up with an array and a hash.

As I said in my original message, "if order matters". For something the size 
and complexity of a conduit it may not be worth bothering, but as 
complexity increases it starts to make a lot of sense to just manage one 
data structure and create any derivatives on-the-fly.

> > I would, however, question the ordering. If I were doing something
> > where I was creating two separate cross-referenced databases, I'd
> > probably be using some kind of record identifier. Palm records all have
> > unique id's, so that would be my first guess. I don't suppose
> > TitraxNoteDB records have a field something like "nameid" or some such,
> > huh?
>
> As far as I can tell, the names and notes do use the same record
> ordering. But you may have a point.  I checked the ID of the records
> themselves, and there doesn't seem to be any correlation between the Name
> and the Note DBs. There are however Record index entries in each of the
> three DBs (TitraxData is the third).  I wasn't sure what they were for
> before, but now I'm thinking they are for cross-referencing the
> databases.

Each record will have its own unique record id. The question, however, is 
whether somewhere in the application specific data structure there might be 
the id's of _other_ records.

That probably has more to do with the order in which entries are created 
than anything else. The record id is just that... an increasing number. 
It's assigned by the PalmOS database subsystem for every record that's 
created. There's no meaning beyond that, I think.

> I'll have to take a closer look at these later.  For now, the records do
> seem to be indexed by record number as well.  I should look over the
> source code for Titrax to see if I can make heads or tales of it one day.

I might be giving the Titrax developers too much credit, you know. For me, 
it would seem nuts to create three databases and just assume that they're 
all going to be completely synchronized. PalmOS is a remarkably stable 
system, but still...

>  If you or anyone else has some insight as to how I should decode this
> info, please let me know.  Below I've provided sample output of pdbdump. 

data, category, attributes and id are all managed by the PalmOS database 
layer. They don't have any specific meaning to Titrax. The data is where 
the app-specific stuff is. Normally, data corresponds to a C structure of 
some kind. Well, a C structure with variable length strings tacked onto the 
end. I'm starting to get the feeling that maybe the Titrax folks decided to 
have a separate database for what would normally be just different fields 
in a structure in a single database?

c.

-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.