hash as argument

Discussion in 'Perl Misc' started by Aaron DeLoach, Jul 8, 2004.

  1. 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
    Aaron DeLoach, Jul 8, 2004
    #1
    1. Advertising

  2. Aaron DeLoach

    Matija Papec Guest

    X-Ftn-To: Aaron DeLoach

    "Aaron DeLoach" <> wrote:
    >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 @_



    --
    Matija
    Matija Papec, Jul 8, 2004
    #2
    1. Advertising

  3. Aaron DeLoach wrote:

    > 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--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Hire me! My resume: http://www.dot-app.org
    Sherm Pendley, Jul 8, 2004
    #3
  4. That's one method I didn't try... but it worked.

    Thanks

    "Matija Papec" <> wrote in message
    news:...
    > X-Ftn-To: Aaron DeLoach
    >
    > "Aaron DeLoach" <> wrote:
    > >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 @_
    >
    >
    >
    > --
    > Matija
    Aaron DeLoach, Jul 8, 2004
    #4
  5. "Sherm Pendley" <> wrote in message
    news:...
    > Aaron DeLoach wrote:
    >
    > > 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.


    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!

    >
    > 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--
    >
    > --
    > Cocoa programming in Perl: http://camelbones.sourceforge.net
    > Hire me! My resume: http://www.dot-app.org
    Aaron DeLoach, Jul 8, 2004
    #5
  6. Aaron DeLoach wrote:

    > 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--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Hire me! My resume: http://www.dot-app.org
    Sherm Pendley, Jul 8, 2004
    #6
  7. Aaron DeLoach

    Joe Smith Guest

    Sherm Pendley wrote:
    > 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
    Joe Smith, Jul 9, 2004
    #7
  8. Joe Smith wrote:

    > 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--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Hire me! My resume: http://www.dot-app.org
    Sherm Pendley, Jul 9, 2004
    #8
  9. Aaron DeLoach

    Andrew Hamm Guest

    Sherm Pendley wrote:
    > Joe Smith wrote:
    >
    >> 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'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...
    Andrew Hamm, Jul 9, 2004
    #9
  10. Sherm Pendley, Jul 9, 2004
    #10
  11. Aaron DeLoach

    Daedalus Guest

    > 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
    Daedalus, Jul 9, 2004
    #11
  12. Aaron DeLoach

    Anno Siegel Guest

    Daedalus <> wrote in comp.lang.perl.misc:
    > > 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.


    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
    Anno Siegel, Jul 9, 2004
    #12
  13. On Fri, 09 Jul 2004 07:11:50 GMT, Joe Smith <> wrote:
    > 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.
    John J. Trammell, Jul 9, 2004
    #13
  14. Aaron DeLoach

    Matija Papec Guest

    X-Ftn-To: Andrew Hamm

    "Andrew Hamm" <> wrote:
    >> 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...


    Agree; I'll second that. :!



    --
    Matija
    Matija Papec, Jul 9, 2004
    #14
  15. double quotes vs. single quotes (was Re: hash as argument)

    Joe Smith <> wrote:
    > Sherm Pendley wrote:
    >> And don't use double-quotes on strings unless it's necessary.

    >
    > 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 SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Jul 9, 2004
    #15
  16. Anno Siegel <-berlin.de> wrote:

    > 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 SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Jul 9, 2004
    #16
  17. John J. Trammell <> wrote:
    > On Fri, 09 Jul 2004 07:11:50 GMT, Joe Smith <> wrote:
    >> 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 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>


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Jul 9, 2004
    #17
  18. In article <ccm3tf$9ra$-Berlin.DE>, Anno Siegel wrote:
    [snip]
    > 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.

    >> 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


    Kevin
    Kevin Collins, Jul 9, 2004
    #18
  19. Re: double quotes vs. single quotes (was Re: hash as argument)

    In article <>, Tad McClellan wrote:
    > Joe Smith <> wrote:
    >> Sherm Pendley wrote:
    >>> And don't use double-quotes on strings unless it's necessary.

    >>
    >> 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'


    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
    Kevin Collins, Jul 9, 2004
    #19
  20. Aaron DeLoach

    Anno Siegel Guest

    Kevin Collins <> wrote in comp.lang.perl.misc:
    > In article <ccm3tf$9ra$-Berlin.DE>, Anno Siegel wrote:
    > [snip]
    > > 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.


    ....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
    Anno Siegel, Jul 9, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bhushit Joshipura

    defaulting argument to previous argument

    Bhushit Joshipura, Dec 29, 2003, in forum: C++
    Replies:
    5
    Views:
    410
  2. Ben Kial
    Replies:
    1
    Views:
    643
    Eric Enright
    Nov 15, 2004
  3. S?ren Gammelmark
    Replies:
    1
    Views:
    1,879
    Eric Sosman
    Jan 7, 2005
  4. rp
    Replies:
    1
    Views:
    512
    red floyd
    Nov 10, 2011
  5. Srijayanth Sridhar
    Replies:
    19
    Views:
    608
    David A. Black
    Jul 2, 2008
Loading...

Share This Page