%assocary = (1,2,3,4,5,6,7,8);
# How come
$scalar = (@array = keys(%assocary));
print $scalar , "\n";
# prints 4 (which I expect), but
$scalar = keys(%assocary);
print $scalar , "\n", length($scalar), "\n";
# prints an empty string from $scalar (length 0)?
# I thought that `keys' returned
# a normal array, like THE BOOK says (what other book is there :-)
# I shouldn't need the nested array assignment, should I?
__END__
perl -v says
This is perl, version 4.0
$RCSfile: perl.c,v $$Revision: 4.0.1.6 $$Date: 91/11/11 16:38:45 $
Patch level: 19
Copyright (c) 1989, 1990, 1991, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 4.0 source kit.
No, you should. You're assuming that perl understands some
general rule on how to convert an array expression into a
scalar one. It doesn't. Whenever you see it happening,
it's just another special-case hack. This will never work:
die "no pwent for $>" unless getpwuid($>);
Well, until Larry changes the rules, that is.
You're used to formal languages which developed from a
small set of rational principles from which a number
of orthogonal, general rules are derived. Perl is no
such language.
--tom
It just so happens :-) that patch 20 introduces scalar meanings of the
get* routines. The general rule is that they return the name
of the entry, unless you're doing the lookup by name, in which case
they return the "other" thing, whatever that is. Undef on failure,
as usual.
It's even documented. Horrors...
[When, you say? I was hoping to get 20 out several days ago, but I've
been out with the flu for most of a week.]
: You're used to formal languages which developed from a
: small set of rational principles from which a number
: of orthogonal, general rules are derived. Perl is no
: such language.
Well, yes. Perl is an informal language which developed from a
large set of irrational principles from which a number of
(somewhat) orthogonal, general rules are derived. Automatic
conversion of lists to scalars is No Such Rule.
There are several other such Sacred Rules that don't exist in Perl.
The most Sacred Rule in Perl is this: it probably does what you want
most of the time. And when it doesn't, it's easy to work around.
What's odd is how, every time I did introduce a new Sacred Rule, people
complained that it wasn't doing what they expected any more. I don't
think most people learn things by rule. I think they learn things by
example and by custom, even in a language that's built of supposedly
orthogonal rules.
There are exceptions, of course--such as those disgusting people who
can glance at a complex declaration in C and immediatly tell you
exactly what it means. :-)
Orthogonality is overrated. Yes, it's beautiful to put all your
features into an n-dimensional space, but you generally find that most
of the junctions in your matrix are useless. Then you end up throwing
in some glue to help you model the real world, and your orthogonality
has merely swept the complexity under someone else's carpet, namely
whoever has to keep the gluepot hot. Perl tries to glue the carpet down.
Yes, I'm overstating my case. Yes, it's good to have a certain amount
of abstract independence. But the real world consists of relationships,
and every relationship is different. No feature is an island. Perl
is more like a hot glue gun than a snap-together model.
Now you see what happens when you go and push my hot glue button...
Larry