[ABE.pm] Re: Accessing data in an array?

[Ricardo SIGNES]

* Faber Fedor <faber at linuxnj.com> [2004-12-01T19:21:28]
> On 30/11/04 11:45 -0500, Ricardo SIGNES wrote:
> > * Faber Fedor <faber at linuxnj.com> [2004-11-30T11:24:17]
> > Don't use prototypes.  They don't do what most people think, and they
> > end up causing a lot of trouble.  Take it from Tom C, one of the Camel
> > authors:
> > 
> > 	http://library.n0i.net/programming/perl/articles/fm_prototypes/
> 
> IIUC, I should just do a "sub foobar {"  instead of a "sub foobar($$)
> {"?  If so, that would allow me the variable arguments I Was looking for
> earlier tonight.

Right.

> > Also, don't mix tabs and spaces!  Was that really your doing?
> 
> My vi(m) is supposed to replace all tabes with spaces.

That's just sick.  Still, better than mixing. :)

> > So, @incides here is a global, or at least declared in a larger
> > containing scope?  It looks like what you want to do, there, is return
> > attributes for the hashref with the given value in a specific key.
> > 
> > My first note would be that you'd be better served by a HOH -- a hash of
> > hashes or, more properly, a hash in which the values are references to
> > hashes.
> 
> That's what I was thinking, but that means going back and changing alot
> of code.

Could be.  You could always do the things below, or create an adapter to
let you access the icky stuff via a nicer interface.  You might consider
this too much work.  (You'd use something like a hash tied to the array
with an interface class.)

> > Also note that I'm calling it "key" instead of "index."  Index is
> > usually positional, like in an array, but you're looking for an
> > unordered match, like a hash key.  (Another red flag that you should be
> > using a HOH!)
> 
> Sorry.  The word "index" refers to the the finacial index that we are
> using; the S&P 500 index, the NYSE index, etc..

Ha!  Ok.
 
> > > sub foobar($) {
> > 
> > Where "foobar" should be "print_entry" or something?  Don't confuse me
> > more than regular life already does!
> 
> Actually, "foobar" is generating an SQL statement; how is that any
> different than a print_entry function for the purpose of the discussion?

Giving it a name that describes what it does helps me quickly understand
things.  That's all.

> > Personally, I'd just return the hashref from lookup_values_for, so it
> > returned { key => x, volume => y, weight => z } (well, really I'd use a
> > HOH, but...):
> > 
> >  sub display_entry {
> >    my ($key) = @_;
> >    return unless my $entry = lookup_entry_for($key);
> >    printf "%10s: %u\n", $_, $entry->{$_} for qw(key volume weight);
> >  }
> 
> Returning a hash to a scalar makes the scalar a hashref? Intriguing.

No, I said "return the hashref."  You can't return a hash, only a scalar
or a list.  If you return a hash, it will be returned as an array. If
you assign an array to a scalar, you get the length.  That's not what
you want!

Given a hash %dictionary, it's very easy to C< return \%dictionary >

Or, be very Perlish:  return wantarray ? %dictionary : \%dictionary;

In scalar context, return a ref.  Otherwise, the hash.  (Well, it's not
very Perlish because it's not very useful, but...)

-- 
rjbs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.pm.org/archives/abe-pm/attachments/20041201/4ca3db03/attachment.bin