my ( $count ) = $sth->fetchrow_array();
[download]

my $count = $sth->fetchrow_array();
[download]

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

fetchrow_array() returns an array. If you assign it like:
my $count = $sth->fetchrow_array();
$count will always equal [the] scalar context of the array

Subroutines return lists not arrays. A list is a series of scalars, an array is a bag that contains a list.

Therefore, $count will be the scalar context of the list. Lists in scalar context evaluate to the their rightmost element. If you actually wanted the behavior you describe above, you'd need to put it inside a "list bag", more commonly called an array:

my $count = @{[ $sth->fetchrow_array() ]};
[download]

In this case $count would be the number of elements returned, namely 1.

-Blake

After giving what I believed to be a complete answer yesterday, I realized that it still wasn't quite correct. It is true that subroutines return lists not arrays, but when called in scalar context they dont necessarily return the scalar value of that list.

The most obvious example of this is localtime() whose return values in scalar and list context have little to do with one another. Another example happens to be fetchrow_array()

From the DBI pod:

In a scalar context, fetchrow_array returns the value of the first field. An undef is returned if there are no more rows or if an error occurred. Since that undef can't be distinguished from an undef returned because the first field value was NULL, you should exercise some caution if you use fetchrow_array in a scalar context.

Using my logic, in scalar context we'd get the last field not the first.

The moral of the story is that the behavior of a subroutine in scalar context can't be determined from its list context return value.

Here are three subs that return the same values in list context, but behave differently in scalar context:

#!/usr/bin/perl -wT
use strict;

sub test1 {
  return @{[ qw(A B C) ]};
}

sub test2 {
  return qw(A B C);
}

sub test3 {
  return wantarray ? qw(A B C) : 'I like jellybeans';
}

print "List context\n",
      "  test1: ", join(', ',test1()), "\n",
      "  test2: ", join(', ',test2()), "\n",
      "  test3: ", join(', ',test3()), "\n",
      "\nScalar context\n",
      "  test1: ", scalar test1(), "\n",
      "  test2: ", scalar test2(), "\n",
      "  test3: ", scalar test3(), "\n";

=OUTPUT
List context
 test1: A, B, C
 test2: A, B, C
 test3: A, B, C

Scalar context
 test1: 3
 test2: C
 test3: I like jellybeans
[download]

-Blake

I find an interesting bug in the following example:

#!/usr/bin/perl

my @array = qw(fred ethel ricky lucy);
my $scalar = @array;

print $scalar, "\n";

exit;
[download]

perl seems to be using a character set that creates the numeral one in a glyph that's just like the US English numeral four. Odd.

SELECT COUNT(*) returns a single value. fetchrow_array returns an array. If you put the two together, you'll get the row count returned in a single-element array. Here's the correct example:

my @array  = (42);
my $count  = @array;
my ($elem) = @array;
print "$count element, which is ($elem)\n";
[download]

Update: Oops, it does return a list. The specification even says that it returns the value of the first field in scalar context (a little wantarray action). I'd have missed the boat completely if it didn't go on to warn about calling it in scalar context, though I didn't read that initially.

Hey everyone, look over there => !