view release on metacpan or  search on metacpan

BBDB.pm  view on Meta::CPAN

632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
 ("nadine.and.henry@pobox.com"        The net addresses - a list of strings
  "maztravel@maztravel.com")
 ((creation-date . "1999-09-02")      The notes field - a list of alists
  (timestamp . "1999-10-17")
  (notes . "Always split aces and eights")
  (birthday "6/15")
 )
 nil                                  The cache vector - always nil
 ]
 
After this is decoded it will be returned as a reference to a BBDB
object.  The internal structure of the BBDB object mimics the lisp
structure of the BBDB string.  It consists of a reference to an array
with 9 elements The Data::Dumper output of the above BBDB string would
just replaces all of the ()s with []s.  It can be accessed by using
the C<$bbdb->part('all')> method. For completeness, here is the output
of Data::Dumper for the above record:
 
 $VAR1 = bless( {
                 'data' => [
                             'Henry',

BBDB.pm  view on Meta::CPAN

865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
=cut
 
 
=head1 BUGS
 
In version 2.32 of BBDB, despite what the documentation says, it seems
that zip codes are always stored quoted strings, even though it seems
to be impossible to enter anything other than an integer.  
 
Phone numbers may be converted from strings to integers if they are
decoded and encoded.  This should not affect the operation of BBDB.
Also a null last name is converted from "" to nil, which also doesn't
hurt anything.
 
You might ask why I use arrays instead of hashes to encode the data in
the BBDB file.  The answer is that order matters in the bbdb file, and
order isn't well defined in hashes.  Also, if you use hashes, at least
in the simple minded way, you can easily find yourself with legitimate
duplicate keys.