in reply to Function Prototypes and Array vs. List (Pt. 2)
But you aren't "convert[ing] or expand[ing] an array into a list"; you're converting a list into a scalar. That's what the prototype means. It might not be what most people would want prototypes to mean, but that' still what the prototype means.
How do you convert a list to a scalar? Easy. Meditate on this bit from perlfunc:
Remember the following important rule: There is no rule
that relates the behavior of an expression in list context
to its behavior in scalar context, or vice versa.
There is no general rule.
You have to read the documentation for whatever it is you're using.
Re^2: Function Prototypes and Array vs. List (Pt. 2)
by tadman (Prior) on Jun 13, 2002 at 14:28 UTC
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
create($bob[0])
Case closed.
-- Randal L. Schwartz, Perl hacker
update:
And if you can show me where you "Well, sometimes you've just got to." in actual useful code and not some junky little hypothetical misdesign, I'd be surprised. | [reply] [Watch: Dir/Any] [d/l] [select] |
|
I'd say the specification of create is incomplete.
Prototyping does act surprisingly because it goes against
the list flattening you'd expect from unprototyped functions.
Not specifying that a function is prototyped, or not saying
that the first argument will be evaluated in scalar context
means, IMO, that the description is incomplete (and hence wrong).
I only use prototypes if there are clear benefits (\@
and & prototypes, sometimes a prototype with a
single $ (which changes the way perl compiles your
Perl)). But often it's too much of a nuisance.
I also don't agree with your reasoning that with such a simple
description of create you should use $array[0]
Take a look at the description of POSIX::strftime.
With your reasoning, the proper way of calling it would be:
use POSIX;
my @chunks = localtime;
print strftime "some format", $chunks [0], $chunks [1], $chunks [2
+],
$chunks [3], $chunks [4], $chunks [5
+],
$chunks [6], $chunks [7], $chunks [8
+];
instead of
print strftime "some format", localtime;
strftime could have been prototyped as
$$$$$$$;$$$; the description doesn't say
it's not, and spells out the arguments for strftime.
Abigail
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
|
No, your hypothetical create method is simply wrong. It's buggy. It should be (to paraphrase John Cleese) a NON-method. It should be bereft of life and pushing up the daisies.
The only reason to use prototypes is in order to give your functions the same syntax as various Perl builtins. E.g., with prototypes you can write a mymap that will have the same semantics as map. Your ``create'' method isn't doing that; it's using a prototype in order to create a bug.
I could equally well claim that map is broken, because this code
my %hash = map { $_ => X => 1 } qw(a b c d)
does something very strange.
You're right about coding, though: In order to make sure code does not have a bug, it is not enough to check documentation. You must look at the code.
Why are you using a prototype? So far you've shown excellent reasons for you not to use a prototype for this function. ``Doctor, whenever I leave the spoon in the cup and drink my tea, my eye hurts!''
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Eh, no, it's using a prototype to act as Perl buildins....
Remember that by default, subroutine calls gobble up all the
arguments (unless there are parens), except subroutines
that are prototypes to take zero or one argument.
Witness:
#!/usr/bin/perl -w
use strict;
sub all {print "@_\n"};
sub gobble_no_proto {return};
sub gobble_proto ($) {return};
all "foo", "bar", gobble_no_proto "baz", "quux", "fluff";
all "foo", "bar", gobble_proto "baz", "quux", "fluff";
__END__
foo bar
foo bar quux fluff
See the difference?
Abigail
| [reply] [Watch: Dir/Any] [d/l] |
|
|