Re: Function Prototypes
by GrandFather (Saint) on Nov 24, 2015 at 02:02 UTC
|
sub ConfigRead {
my %hArgs = @_;
# stick some cool stuff in their variables
}
Then instead of:
die "horribly" if $hArgs{sFILE} eq 'BAD';
you can:
die "horribly" if !exists $hArgs{sFILE};
or:
$hArgs{sFILE} //= 'default.sFile';
as appropriate.
Premature optimization is the root of all job security
| [reply] [Watch: Dir/Any] [d/l] [select] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
Re: Function Prototypes
by hippo (Bishop) on Nov 24, 2015 at 13:21 UTC
|
Your args as in the example are a hash, so in the absence of any indication of why you want to use prototypes the obvious works for me:
#!/usr/bin/perl -w
use strict;
my @aFieldHeaders;
my %hFieldConfigs;
sub ConfigRead (%);
my $sConfigFile = 'mydata.csv';
ConfigRead(sFILE => $sConfigFile,
apHEAD => \@aFieldHeaders,
hpFIELDCONF => \%hFieldConfigs);
# my array and hash now have some cool stuff in 'em!
sub ConfigRead (%) {
my %hArgs = (
sFILE => 'BAD', # lazy user alert! whine & die
apHEAD => 'BAD', # ^^^ see comment above
hpFIELDCONF => 'BAD', # by now you know the drill!
@_, # user demands come from here
);
# stick some cool stuff in their variables
}
But as everyone else has said: don't do that unless you have a good reason. | [reply] [Watch: Dir/Any] [d/l] |
|
You, hippo, are my hero! And now that I see it, it makes perfect sense. Occam's Razor, after a good stropping.
As promised: THANK YOU!
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
|
I still do not understand your original reasons for wanting to use prototypes, nor do I know if hippo's reply has dissuaded you, but if you are not dissuaded, here's an example of why prototypes are not useful as you seem to wish to use them:
c:\@Work\Perl\monks>perl -wMstrict -le
"use Data::Dump qw(dd);
;;
sub S_ { my %h = @_; dd \%h; }
sub Sh (%) { my %h = @_; dd \%h; }
sub Sa (@) { my %h = @_; dd \%h; }
;;
S_(qw(a b c));
Sh(qw(a b c));
Sa(qw(a b c));
"
Odd number of elements in hash assignment at -e line 1.
{ a => "b", c => undef }
Odd number of elements in hash assignment at -e line 1.
{ a => "b", c => undef }
Odd number of elements in hash assignment at -e line 1.
{ a => "b", c => undef }
The warning is in the 'misc' class, and escalating such warnings to FATALity would at least prevent the code from soldiering on regardless, but of course that has nothing to do with the prototype.
Give a man a fish: <%-{-{-{-<
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Function Prototypes
by muba (Priest) on Nov 24, 2015 at 01:37 UTC
|
If coded as is (below), the sub works;
Cool cool.
There's a lot of things to say about the way Perl passes arguments into a subroutine through this weird @_ variable. But don't you just love it how it allows you to write stuff like my %hArgs = (default1 => "foo", default2=> "bar", @_); ... inside a sub, and then call that sub with ConfigRead default2 => "banana juice", extra => "new key/value pair w00t w00t"; and it just works and you preserve one default setting, override another, and even introduce a third setting? It's things like that make adore this language.
So thumbs up to you, KimberTLE, for coming up with a solution that works. And I don't mean that sarcastically, I am indeed sincere. So... is there a question?
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Function Prototypes
by Anonymous Monk on Nov 24, 2015 at 01:48 UTC
|
| [reply] [Watch: Dir/Any] [d/l] |
Re: Function Prototypes
by Anonymous Monk on Nov 24, 2015 at 01:32 UTC
|
IMHO, it should look like this:
# the line above was intentionally left blank
In other words, don't use prototypes at all... | [reply] [Watch: Dir/Any] [d/l] |
|
Thank you for your "In other words, don't use prototypes at all..." quip. It was certainly useful, and I shall cherish it for all time!
Now, why do you think I asked for assistance with how to code the prototypes? Do you think it's because I don't like prototyping, or do you think it's because I prefer prototyping? I'll give you a few seconds to consider your answer...
| [reply] [Watch: Dir/Any] |
|
If you come from a strictly typed language like C++, prototypes seem like a good idea. In Perl almost always they aren't. Which is why mentioning prototypes in Perl often elicits a "Don't do that!" response.
What is your good reason for using prototypes? (There are some.)
Your sample non-prototype code looks pretty good to me because you have effectively named the parameters where they are being passed. That is hugely better documentation for someone reading the code later than simply passing a list and hoping for the best. Perl prototypes don't give type safety - they tend to enforce type matching which puts them on a level with C style casts. See Prototypes for the full glory of function prototyping.
Premature optimization is the root of all job security
| [reply] [Watch: Dir/Any] |
|
|
| [reply] [Watch: Dir/Any] [d/l] |
Re: Function Prototypes
by u65 (Chaplain) on Nov 24, 2015 at 12:32 UTC
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |