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

[Faber Fedor]

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.

> Also, don't mix tabs and spaces!  Was that really your doing?

My vi(m) is supposed to replace all tabes with spaces.

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

> Failing that:
> 
>  my @matches = grep { $_->{key} eq $key } @indices;
>  return unless @matches; # nothing matched
>  die "more than one match!!" if @matches > 1; # too many matches!
>  return ($matches[0]{volume}, $matches[0]{weight}); # the only match
> 
> Note that I have to handle "more than one match" here, because a LOH
> can't enforce uniqueness on the index key.  A HOH could.  I still think
> this code is ugly, but it should demonstrate the point.

It's just a more Perlish way of doing what I thought to do.

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

> >     my ($index) = @_;
> >     my (weight, cap) = returnIndicesValues($index);
> >     print "index = $index \t weight = $weight \t cap = $cap\n";
> > }
> > I just figure there's a nicer, more Perl-ish solution.
> 
>  sub display_entry {
>    my ($key) = @_;
>    return unless my @values = lookup_values_for($key);
>    print "key: $key\nvolume: $values[0]\nweight: $values[1]\n";
>  }

Well, that certainly is more Perl-ish.

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



-- 
 
Regards,
 
Faber                     

Linux New Jersey: Open Source Solutions for New Jersey
http://www.linuxnj.com