hash as argument

[Aaron DeLoach]

I am trying to call a sub with two arguments. One being a hash generated
from a sub, the other being a string. I've tried other variations but can
only get the receiving sub to recognize either the hash or the string, but
never both.

e.g, &do_something(&create_hash, "This is the string.");

sub do_something
{
my (%hash, $string) = @_;

process...
}

sub create_hash
{
my %h;
# construct the hash ...
return %h;
}

Can anyone get me in the right direction?

Regards,
Aaron

 

[Matija Papec]

X-Ftn-To: Aaron DeLoach

I am trying to call a sub with two arguments. One being a hash generated
from a sub, the other being a string. I've tried other variations but can
only get the receiving sub to recognize either the hash or the string, but
never both.

e.g, &do_something(&create_hash, "This is the string.");

sub do_something
{
my (%hash, $string) = @_;

process...
}

sub create_hash
{
my %h;
# construct the hash ...
return %h;
}

Can anyone get me in the right direction?

Try,
my ($string, %hash) = @_;

this is for the same reason you can't
my (@arr, $string) = @_;

as @arr gets all arguments from @_

 

[Sherm Pendley]

I am trying to call a sub with two arguments. One being a hash generated
from a sub, the other being a string. I've tried other variations but can
only get the receiving sub to recognize either the hash or the string, but
never both.

e.g, &do_something(&create_hash, "This is the string.");

You are using Perl 5.x, right? Not Perl 4? Unless you're using Perl 4, or
you know precisely what the & does and why you want to do that, don't use
it. And don't use double-quotes on strings unless it's necessary.

do_something(create_hashref(), 'This is a string');

sub do_something
{
my (%hash, $string) = @_;

process...
}

sub do_something {
my ($hashref, $string) = @_;

# Use a hash reference
my @keys = keys(%$hashref);
}

sub create_hash
{
my %h;
# construct the hash ...
return %h;
}

sub create_hashref {
my $h = {};

# Store something via the hashref
$h->{'foo'} = 'bar';
$h->{'baz'} = 'buzz';

return $h;
}

Can anyone get me in the right direction?

See also:

perldoc perldsc
perldoc perllol

sherm--

 

[Aaron DeLoach]

That's one method I didn't try... but it worked.

Thanks

 

[Aaron DeLoach]

You are using Perl 5.x, right? Not Perl 4? Unless you're using Perl 4, or
you know precisely what the & does and why you want to do that, don't use
it. And don't use double-quotes on strings unless it's necessary.

Perl 5.x

I use the '&' mainly to distinguish sub calls. Why not?

I used the double-quotes in the example.

Thanks for your help!

 

[Sherm Pendley]

I use the '&' mainly to distinguish sub calls. Why not?

It's deprecated for normal use in Perl 5. It disables prototype checking,
and passes the current @_ to the called sub instead of creating a lexically
scoped @_ within the sub.

So unless you're using a Very Old Perl, or you have a specific reason for
needing one of the above effects, don't use & to call subs.

A better way to make sub calls more visually distinctive is to always use
the ()s, even when you're not passing any arguments. That helps them stand
out visually, but doesn't have the unwanted side-effects of using &.

sherm--

 

[Joe Smith]

And don't use double-quotes on strings unless it's necessary.

Has Larry Wall made a statement on this?

Using double quotes in a situation where single quotes could also
be used is not a programming error. It is a matter of style.
-Joe

 

[Sherm Pendley]

Has Larry Wall made a statement on this?

I think his statement that "there's more than one way to do it" is relevant.
Quite a shame so many folks have forgotten it.

It is a matter of style.

I agree, but there are a few regulars here who view it as a matter of
religion. Minimizing the use of double-quotes, at least when posting code
here, helps reduce the incessant whining about it.

I'd fight the good fight if it mattered, but in this case there's nothing to
be gained by arguing the point.

sherm--

 

[Andrew Hamm]

I think his statement that "there's more than one way to do it" is
relevant. Quite a shame so many folks have forgotten it.


I agree, but there are a few regulars here who view it as a matter of
religion. Minimizing the use of double-quotes, at least when posting
code here, helps reduce the incessant whining about it.

I'm not changing - I hate it when I spend 15 minutes looking for a bug only
to finally discover I've tried to add $thingy inside single quotes. Too he11
with that...

 

[Sherm Pendley]

I'm not changing

So now someone wants to debate whether it's a subject worth arguing about.
Oy! You just can't win with this group...

sherm--

 

[Daedalus]

So now someone wants to debate whether it's a subject worth arguing about.

Oy! You just can't win with this group...

Arguing on programming habits and style is pretty trivial... in both
direction.
We could say that uses of double-quotes should only be prefered when their
behavior is needed, but we could also say that uses of single-quote should
only be prefered when their behavior is needed. Double-quotes make it easier
to add variables or backslash-escapes, while single-quote make it clearer
that there's no interpolation. To me their uses are a matter of choice. But
saying "misuse of double-quotes" or ask to "fix" the thing... Do it because
the majority is doing it, thats not a rule of perl.
Pointing to the fact that many people would not even look at the code
because they don't like the "prefer double-quote" style is fine, it's good
to know, but asking someone to fix something that is not broken is another.
It's not like the thing is an ancien obscur use like using $mains'var
instead of $main::var. "If it ain't broke don't fix it".

It's an opinion, you people are free to like it or not, but it's mine and
I'm free to have it.
DAE

 

[Anno Siegel]

Arguing on programming habits and style is pretty trivial... in both
direction.
We could say that uses of double-quotes should only be prefered when their
behavior is needed, but we could also say that uses of single-quote should
only be prefered when their behavior is needed. Double-quotes make it easier
to add variables or backslash-escapes, while single-quote make it clearer
that there's no interpolation. To me their uses are a matter of choice. But
saying "misuse of double-quotes" or ask to "fix" the thing... Do it because
the majority is doing it, thats not a rule of perl.

It is a more general rule of human interaction. It is often useful
to do things in one, agreed-upon way, even if there is no rational
reason why that particular way should be preferred. Traffic regulations
(beginning with the side of the road you drive on) are often quite
arbitrary, but the advantages of adhering to them are obvious.

Similarly, for a programming community, there are advantages in having
conventional preferences for one style over another when technically
two (or more) ways would give the same result. By using the conventional
style, the author tells the reader "Nothing to see here, move along...".
A deviation from the standard tells the reader to look for the reason.
That makes such code a lot easier to read.

Thus, a set of stylistic conventions gives a language a dimension of
expressiveness it wouldn't have without it. That is a Good Thing.
The preference of '' over "" and of sub() over &sub belong in this
category.

Pointing to the fact that many people would not even look at the code
because they don't like the "prefer double-quote" style is fine, it's good
to know, but asking someone to fix something that is not broken is another.
It's not like the thing is an ancien obscur use like using $mains'var
instead of $main::var. "If it ain't broke don't fix it".

It's not about "correct" or "broken", it's about clarity.

Anno

 

[John J. Trammell]

Using double quotes in a situation where single quotes could also
be used is not a programming error. It is a matter of style.

AOL. One IMHO legit reason to prefer double quotes is that ' and "
are more visually distinct than ` and '.

I'd argue the " vs. ' beef isn't in the same league as use strict,
test return value from open(), avoid C-style loops, and most others.

 

[Matija Papec]

X-Ftn-To: Andrew Hamm

I'm not changing - I hate it when I spend 15 minutes looking for a bug only
to finally discover I've tried to add $thingy inside single quotes. Too he11
with that...

Agree; I'll second that. :!

 

[Tad McClellan]

Has Larry Wall made a statement on this?

Not that I know of, but I've heard both Randal Schwartz and
Tom Christiansen say that they always use double quotes...

I'm of the "use double quotes only if you _need_ double quotes" camp,
because I'm just a Regular Guy and not a Genius Hacker.

The rules are different between those demographics.

I need all the "brain cycles" available to solve the problem,
I don't have excess that I can spend on checking for edge cases.



The programmer's choice of quotes is a note to (him|her)self:

"interpolation or backslash escapes are here!"
or
'nothing special going on here'


Double quotes without interpolation or backslash escapes tricks
the maintenance programmer into spending more debugging time on
that string than is necessary.

(assuming a string of more than just a few characters)

Using double quotes in a situation where single quotes could also ^^^^^^^^^^^
be used is not a programming error.

But then you have to remember to analyse the situation everytime
you want to quote a string.

$re = "func\(\)";
print "matched [$1]\n" if /($re)/; # matches "func" without parens


Gets false matches with "", would have worked fine the 1st time with ''.

It is a matter of style.

Yes, but that is what style choices are for.

Either to make debugging easier, or to reduce the chances of
inserting bugs in the first place.

The above-mentioned "rule" does both.

 

[Tad McClellan]

By using the conventional
style, the author tells the reader "Nothing to see here, move along...".
A deviation from the standard tells the reader to look for the reason.
That makes such code a lot easier to read.

Some more examples of saying that "something special" is going
on when nothing special is going on:

m/RE/s; # when RE does not contain a dot

m/RE/m; # when RE does not contain ^ or $ anchors

printf "%s\n", 'Hello World'; # printf() w/same formatting as print()

 

[Tad McClellan]

AOL. One IMHO legit reason to prefer double quotes is that ' and "
are more visually distinct than ` and '.

I always use qx/prog/ instead of `prog` because it is more
visually distinct, so that reason isn't legit in _my_ code.

I'd argue the " vs. ' beef isn't in the same league as use strict,
test return value from open(), avoid C-style loops, and most others.

<aol>Me too!</aol>

 

[Kevin Collins]

Thus, a set of stylistic conventions gives a language a dimension of
expressiveness it wouldn't have without it. That is a Good Thing.
The preference of '' over "" and of sub() over &sub belong in this
category.

Use of sub() and &sub is not "preference" - they have specifically different
behaviors.

It's not about "correct" or "broken", it's about clarity.

Anno

Kevin

 

[Kevin Collins]

Not that I know of, but I've heard both Randal Schwartz and
Tom Christiansen say that they always use double quotes...

I'm of the "use double quotes only if you _need_ double quotes" camp,
because I'm just a Regular Guy and not a Genius Hacker.

The rules are different between those demographics.

I need all the "brain cycles" available to solve the problem,
I don't have excess that I can spend on checking for edge cases.



The programmer's choice of quotes is a note to (him|her)self:

"interpolation or backslash escapes are here!"
or
'nothing special going on here'

Its funny, because my own mental rule is:

"normal string with interpolation if needed"

or

'definitely do not interpolate'

In other words, I typically ONLY use single-quotes when I want to make it clear
that there is some thing that I *don't* want interpolated, like:

my $var = 'this string contains a literal $var';

Double quotes without interpolation or backslash escapes tricks
the maintenance programmer into spending more debugging time on
that string than is necessary.

(assuming a string of more than just a few characters)

Using double quotes in a situation where single quotes could also ^^^^^^^^^^^
be used is not a programming error.

But then you have to remember to analyse the situation everytime
you want to quote a string.

$re = "func\(\)";
print "matched [$1]\n" if /($re)/; # matches "func" without parens


Gets false matches with "", would have worked fine the 1st time with ''.

It is a matter of style.

Yes, but that is what style choices are for.

Either to make debugging easier, or to reduce the chances of
inserting bugs in the first place.

The above-mentioned "rule" does both.

Kevin

 

[Anno Siegel]

Use of sub() and &sub is not "preference" - they have specifically different
behaviors.

....as do "" and ''. If it matters, there is no choice, and no room for
preference. But in many, many cases both choices have (provably) the
same result. It is in these cases, where the programmer has to make
a choice between equivalent notations, that a preference rule helps.

Anno