[31566] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 2825 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 19 00:09:26 2010

Date: Thu, 18 Feb 2010 21:09:11 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Thu, 18 Feb 2010     Volume: 11 Number: 2825

Today's topics:
    Re: (lack of) Helpfulness of Perl error messages. <ben@morrow.me.uk>
    Re: Anyone willing to modify 3rd party perl code? (Seymour J.)
    Re: benchmarks for perl? <ben@morrow.me.uk>
    Re: benchmarks for perl? sln@netherlands.com
    Re: File Position <ben@morrow.me.uk>
    Re: File Position (Randal L. Schwartz)
    Re: File Position <derykus@gmail.com>
    Re: File Position <derykus@gmail.com>
        weird behavior when passing hashes to subroutine <patrickh@gmail.com>
    Re: weird behavior when passing hashes to subroutine sln@netherlands.com
    Re: weird behavior when passing hashes to subroutine <john@castleamber.com>
    Re: weird behavior when passing hashes to subroutine <spamtrap@piven.net>
    Re: weird behavior when passing hashes to subroutine sln@netherlands.com
    Re: weird behavior when passing hashes to subroutine <jurgenex@hotmail.com>
    Re: weird behavior when passing hashes to subroutine <tadmc@seesig.invalid>
    Re: weird behavior when passing hashes to subroutine <sreservoir@gmail.com>
    Re: weird behavior when passing hashes to subroutine <uri@StemSystems.com>
    Re: weird behavior when passing hashes to subroutine <kkeller-usenet@wombat.san-francisco.ca.us>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Thu, 18 Feb 2010 21:36:19 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: (lack of) Helpfulness of Perl error messages.
Message-Id: <jfo057-b2d.ln1@osiris.mauzo.dyndns.org>


Quoth Justin C <justin.0911@purestblue.com>:
> As some of you are probably aware I often have difficulty with Perl and
> I ask for help here usually about once a month. I try to help myself
> where I can, and sometimes, when I'm preparing a minimal example for
> posting here, I find the solution to my problem. That's just happened
> again, but only due to an error message I received from my text editor
> and not Perl directly. 
> 
> I'm a Mac user, and code using TextMate <URL:http://macromates.com/>, it
> has the ability to run code, I don't know how it does it, though, and
> it's error message gave me the clue to the solution of my problem. The
> error message on my Debian box was non-helpful.
> 
> What is likely to be the cause of the non-helpful error message? Is the
> version of Perl on my Mac likely more recent - I've just checked and on
> my Debian box it's 5.10.0, while on the Mac it's 5.8.8. Does TextMate
> have a built in Perl interpreter that gives better error messages?

You could have answered this easily by running the code from the
command-line on your Mac. (You would have got the same error message as
from TextMate.)

> The error I saw on Debian:
> Not a HASH reference at ... line...
> 
> The error I saw from TextMate:
> Can't coerce array into hash at ... line...

The change in error message is due to the different perl versions. The
'Can't coerce...' message comes from the pseudohash code, which was
removed in 5.10, whereas the 'Not a %s reference' is a generic message
for situations where a value holds the wrong kind of ref.

Before you start thinking this change was a bad idea, try running

    perl -le'my $x = [{a => 1}, "b"]; print $x->{a}'

on both machines and consider how hard *that* would have been to debug
with the 5.8 behaviour :).

Ben



------------------------------

Date: Wed, 17 Feb 2010 15:49:14 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Anyone willing to modify 3rd party perl code?
Message-Id: <4b7c564a$10$fuzhry+tra$mr2ice@news.patriot.net>

In <hlha1q1c69@news6.newsguy.com>, on 02/17/2010
   at 05:46 PM, buck <buck@private.mil> said:

>Assuming makes you an ass.

Is not an expectation[1] an assumption? What does that make you?

BTW, do you work for the US military or are you simply posting with a
domain that you are not entitled to use?

[1] in <hlh9i30c69@news6.newsguy.com>

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org



------------------------------

Date: Thu, 18 Feb 2010 21:40:13 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: benchmarks for perl?
Message-Id: <tmo057-b2d.ln1@osiris.mauzo.dyndns.org>


Quoth bugbear <bugbear@trim_papermule.co.uk_trim>:
> No, I'm not starting yet another perl vs C thread.
> 
> I have some concerns about the performance
> of perl varying more than I would expect
> between different installations I'm maintaining
> (and running my perl code on)

Are these different versions of perl? There are often large differences
in performance between major version, in both directions (depending on
what exactly you're doing).

> Is there a standard benchmark, used (perhaps)
> when people port Perl to different CPUs/OS/compilers?

There is perlbench on CPAN, but I believe it's not considered to be as
representative as it used to be.

Running the core test suite, or the test suite of any large CPAN
distribution that does the sort of work you are interested in, is often
good enough.

Ben



------------------------------

Date: Thu, 18 Feb 2010 18:06:56 -0800
From: sln@netherlands.com
Subject: Re: benchmarks for perl?
Message-Id: <airrn5de2o7fssdl8kr3vlkddhdjog26nn@4ax.com>

On Thu, 18 Feb 2010 16:25:33 +0000, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:

>No, I'm not starting yet another perl vs C thread.
>
>I have some concerns about the performance
>of perl varying more than I would expect
>between different installations I'm maintaining
>(and running my perl code on)
>
I don't know but I just found out that the percentage
of time involved with the 'Growing' (only) of scalars
on a Windows box is from 35 to 100 times more than
on a *nix box. This is due to win32 realloc in the
linked crt library (and this is due to calling heap
primatives), not to Perl itself.

Though pre-allocating buffers will solve the problem
as it calls malloc once and avoids realloc() flavors,
but this is not dynamic.

I'd say this is a big deal, depending on your code.

http://www.perlmonks.org/?node_id=810276

-sln


------------------------------

Date: Thu, 18 Feb 2010 21:22:57 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: File Position
Message-Id: <hmn057-b2d.ln1@osiris.mauzo.dyndns.org>


Quoth merlyn@stonehenge.com (Randal L. Schwartz):
> >>>>> "Jürgen" == Jürgen Exner <jurgenex@hotmail.com> writes:
> 
> Jürgen> Now, that is the critical clue. seek() is based on bytes, so you need a
> Jürgen> position in bytes in order to use seek().
> 
> Historical fact: fseek(3) was originally based on ftell(3)-"cookies", where
> the stdio lib didn't promise to be able to return to any position that it
> hadn't originally handed you from a tell.  As it turns out, those "cookies"
> were always byte positions on every operating system *I* saw stdio implemented
> on.

IIRC Win32's stdio in 'text' mode (the default) uses this mechanism to
get around the CRLF->LF translation.

Ben



------------------------------

Date: Thu, 18 Feb 2010 16:11:47 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: File Position
Message-Id: <86eiki84os.fsf@blue.stonehenge.com>

>>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:

Ben> IIRC Win32's stdio in 'text' mode (the default) uses this mechanism to
Ben> get around the CRLF->LF translation.

Nice to know.  I guess I'm lucky in that I've never had to use Windows
except in internet cafes, where the first step is "download putty"
so I can ssh to a real box.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion


------------------------------

Date: Thu, 18 Feb 2010 16:55:33 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: File Position
Message-Id: <97ee6576-5416-40a5-9331-0d293a641907@c34g2000pri.googlegroups.com>

On Feb 17, 9:22=A0pm, Peter Makholm <pe...@makholm.net> wrote:
> mud_saisem <mud_sai...@hotmail.com> writes:
> > Does anybody know how to read through a file searching for a word and
> > printing the file position of that word ?
>
> If your file contains plain ascii, iso-8859, or another 8bit charset
> it should be easy. The tell() function gives you the current location
> in the file, pos() gives you the location of regexp match, and
> index() directly gives you the location.
>
> So this should work (untested though)
>
> =A0 my $offset =3D 0;
> =A0 while (<$fh>) {
> =A0 =A0 =A0 if (/word/) {
        ^^^^^^^^^^^^

        if ( /word/g ) {


Maybe the OP assumed it was correct because of
the 'tell' addition.



--
Charles DeRykus



------------------------------

Date: Thu, 18 Feb 2010 17:03:47 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: File Position
Message-Id: <40932932-7afe-4784-b7c7-20f1a1d510c0@v20g2000prb.googlegroups.com>

On Feb 18, 4:55=A0pm, "C.DeRykus" <dery...@gmail.com> wrote:
> On Feb 17, 9:22=A0pm, Peter Makholm <pe...@makholm.net> wrote:> mud_saise=
m <mud_sai...@hotmail.com> writes:
> > > Does anybody know how to read through a file searching for a word and
> > > printing the file position of that word ?
>
> > If your file contains plain ascii, iso-8859, or another 8bit charset
> > it should be easy. The tell() function gives you the current location
> > in the file, pos() gives you the location of regexp match, and
> > index() directly gives you the location.
>
> > So this should work (untested though)
>
> > =A0 my $offset =3D 0;
> > =A0 while (<$fh>) {
> > =A0 =A0 =A0 if (/word/) {
>
> =A0 =A0 =A0 =A0 ^^^^^^^^^^^^
>
> =A0 =A0 =A0 =A0 if ( /word/g ) {
>
> Maybe the OP assumed it was correct because of
> the 'tell' addition.
>

You may need to loop to pick up multiple hits
per line too if that was the goal.

--
Charles DeRykus




------------------------------

Date: Thu, 18 Feb 2010 16:43:38 -0800 (PST)
From: Patrick Hartman <patrickh@gmail.com>
Subject: weird behavior when passing hashes to subroutine
Message-Id: <af59e67f-25c7-4ca9-8782-eb5bdb290dee@y7g2000vbb.googlegroups.com>

Hi all, I was working on a program today and made a sub routine that I
was passing a few scalars and also a hash to as arguments. This is
what I initially tried:

my %foo = qw(pepsi cola doctor pepper seven up);
my $bar = 'soda is yummy!';

&drink(%foo,$bar);

sub drink {
    my (%sodas,$opinion) = @_;

    # do whatever here
    print "yummy!";
}

The result was not what I was expecting. The $bar value that I was
expecting to be the $opinion scalar ended up as a extra key in the
%sodas hash as undef, and $opinion was empty. I played around a little
and found that if I reverse the order so the scalar is passed before
the hash, it worked like I was hoping:

my %foo = qw(pepsi cola doctor pepper seven up);
my $bar = 'soda is yummy!';

&drink($bar,%foo);

sub drink {
    my ($opinion,%sodas) = @_;

    # do whatever here
    print "yummy!";
}

Is there a rule as to what order to pass types to a subroutine? I'm a
little confused on this one. Thanks,

Patrick


------------------------------

Date: Thu, 18 Feb 2010 17:44:18 -0800
From: sln@netherlands.com
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <0aqrn5dqft7mt62733ks03324q5qcouoko@4ax.com>

On Thu, 18 Feb 2010 16:43:38 -0800 (PST), Patrick Hartman <patrickh@gmail.com> wrote:

[snip]

>Is there a rule as to what order to pass types to a subroutine? I'm a
>little confused on this one. Thanks,
>
>Patrick

There is no rules in Perl, just syntax. If it doesen't work like
you expect, Perl has no way of knowing, and thinks that's what you intend.
Use strict/warnings to help you out.

Basically, I think this is what you did:

my %sodas = (
  # The never ending list
  'pepsi',
  'cola',
  'doctor',
  'pepper',
  'seven',
  'up',
  'soda is yummy!',
  # Add to the never ending list
);

And, you should have gotten an "Odd number of elements ..."
type of message.

If your looking for a "I before E, except after C"
rhyme, I can't think of any.

Also, you probably don't need ampersand before the function
call.

-sln


------------------------------

Date: Thu, 18 Feb 2010 20:11:50 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <87vdduug7t.fsf@castleamber.com>

Patrick Hartman <patrickh@gmail.com> writes:

> Hi all, I was working on a program today and made a sub routine that I
> was passing a few scalars and also a hash to as arguments. This is
> what I initially tried:
>
> my %foo = qw(pepsi cola doctor pepper seven up);
> my $bar = 'soda is yummy!';
>
> &drink(%foo,$bar);
>
> sub drink {
>     my (%sodas,$opinion) = @_;
>
>     # do whatever here
>     print "yummy!";
> }
>
> The result was not what I was expecting. The $bar value that I was
> expecting to be the $opinion scalar ended up as a extra key in the
> %sodas hash as undef, and $opinion was empty. I played around a little
> and found that if I reverse the order so the scalar is passed before
> the hash, it worked like I was hoping:
>
> my %foo = qw(pepsi cola doctor pepper seven up);
> my $bar = 'soda is yummy!';
>
> &drink($bar,%foo);
>
> sub drink {
>     my ($opinion,%sodas) = @_;
>
>     # do whatever here
>     print "yummy!";
> }
>
> Is there a rule as to what order to pass types to a subroutine? I'm a
> little confused on this one. Thanks,

You have to be aware that the hash eats up @_ (it's the same if you use
an array, i.e. my ( @foo, $bar ) = @_; will result in all of @_ ending
up in @foo).

You could do:

sub drink {
    my $opinion = pop @_;
    my %sodas = @_;
    :
    :
}

pop removes the last item from @_ (in this case) and assigns it to
$opionion.

You can also decide to pass a reference to your hash instead, see

 perldoc perlreftut

-- 
John Bokma                                                               j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development


------------------------------

Date: Thu, 18 Feb 2010 20:21:32 -0600
From: Don Piven <spamtrap@piven.net>
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <cI6dnQ36SeAwaODWnZ2dnUVZ_gGdnZ2d@speakeasy.net>

sln@netherlands.com wrote:
> On Thu, 18 Feb 2010 16:43:38 -0800 (PST), Patrick Hartman <patrickh@gmail.com> wrote:
> 
> [snip]
> 
>> Is there a rule as to what order to pass types to a subroutine? I'm a
>> little confused on this one. Thanks,
>>
>> Patrick
> 
> There is no rules in Perl, just syntax. If it doesen't work like
> you expect, Perl has no way of knowing, and thinks that's what you intend.
> Use strict/warnings to help you out.
> 
> Basically, I think this is what you did:
> 
> my %sodas = (
>   # The never ending list
>   'pepsi',
>   'cola',
>   'doctor',
>   'pepper',
>   'seven',
>   'up',
>   'soda is yummy!',
>   # Add to the never ending list
> );

Well, it would have been more like

drink(qw(pepsi cola doctor pepper seven up), 'soda is yummy').

That's seven arguments.  Now when you do

my (%sodas, $opinion) = @_ ;

the %sodas hash is going to suck up all the items in the argument list, 
and leave nothing for $opinion, so 1) $opinion is going to be undef, and 
2) the last argument is treated as a key, and since there are no more 
elements, that key gets a value of undef.

Reversing the order of arguments ($opinion, %sodas) works because 
$opinion gets the first element of the list, and %sodas sucks down the 
rest of 'em in key/value order.

> And, you should have gotten an "Odd number of elements ..."
> type of message.

That's a compile-time error, since the compiler has to know how many 
elements are in the initializer in order to know if it's an odd number. 
  The compiler won't see a problem with %hash = @_ since it has no clue 
how long @_ is going to be.

Don


------------------------------

Date: Thu, 18 Feb 2010 18:43:46 -0800
From: sln@netherlands.com
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <riurn5981gh2n31fektikoat9r14aiahim@4ax.com>

On Thu, 18 Feb 2010 20:21:32 -0600, Don Piven <spamtrap@piven.net> wrote:

>sln@netherlands.com wrote:
>> On Thu, 18 Feb 2010 16:43:38 -0800 (PST), Patrick Hartman <patrickh@gmail.com> wrote:
>> 
>> [snip]
>> 
>>> Is there a rule as to what order to pass types to a subroutine? I'm a
>>> little confused on this one. Thanks,
>>>
>>> Patrick
>> 
>> There is no rules in Perl, just syntax. If it doesen't work like
>> you expect, Perl has no way of knowing, and thinks that's what you intend.
>> Use strict/warnings to help you out.
>> 
>> Basically, I think this is what you did:
>> 
>> my %sodas = (
>>   # The never ending list
>>   'pepsi',
>>   'cola',
>>   'doctor',
>>   'pepper',
>>   'seven',
>>   'up',
>>   'soda is yummy!',
>>   # Add to the never ending list
>> );
>
>Well, it would have been more like
>
>drink(qw(pepsi cola doctor pepper seven up), 'soda is yummy').
>
>That's seven arguments.  Now when you do
>
>my (%sodas, $opinion) = @_ ;
>
>the %sodas hash is going to suck up all the items in the argument list, 
>and leave nothing for $opinion, so 1) $opinion is going to be undef, and 
>2) the last argument is treated as a key, and since there are no more 
>elements, that key gets a value of undef.
>
>Reversing the order of arguments ($opinion, %sodas) works because 
>$opinion gets the first element of the list, and %sodas sucks down the 
>rest of 'em in key/value order.
>
>> And, you should have gotten an "Odd number of elements ..."
>> type of message.
>
>That's a compile-time error, since the compiler has to know how many 
>elements are in the initializer in order to know if it's an odd number. 
>  The compiler won't see a problem with %hash = @_ since it has no clue 
>how long @_ is going to be.
>
>Don

Thanks, next time I won't do that (or do it a different way).

-sln


------------------------------

Date: Thu, 18 Feb 2010 18:52:03 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <t2urn5dctqn7g9h3jev4p710813s8va4r5@4ax.com>

Patrick Hartman <patrickh@gmail.com> wrote:
>Hi all, I was working on a program today and made a sub routine that I
>was passing a few scalars and also a hash to as arguments. This is
>what I initially tried:
>
>my %foo = qw(pepsi cola doctor pepper seven up);
>my $bar = 'soda is yummy!';
>
>&drink(%foo,$bar);
>
>sub drink {
>    my (%sodas,$opinion) = @_;
>
>    # do whatever here
>    print "yummy!";
>}
>
>The result was not what I was expecting. The $bar value that I was
>expecting to be the $opinion scalar ended up as a extra key in the
>%sodas hash as undef, and $opinion was empty. 

From "perldoc perlsub':
    The Perl model for function call and return values is simple: all
    functions are passed as parameters one single flat list of scalars,

Therefore at the point where you are doing 
	 my (%sodas,$opinion) = @_;
there is no recollection that those values in @_ where once organized
into two distinct variables. And of ourse %s is grabbing as many as it
can.

>sub drink {
>    my ($opinion,%sodas) = @_;

In this case $opinion will grab the first value (it can't grab any
others bedause its a scalar) and thus leaving the rest of the list for
%sodas.

>Is there a rule as to what order to pass types to a subroutine? I'm a
>little confused on this one. 

That question is not really targeting the root issue. But as a rule of
thumb if you want to extract arguments like that then they have to have
a known lenght, i.e. be scalars or hashes or arrays of a known, fixed
length. 
Then on top of that you can also get away with one single hash or array
of random length at the very end of the argument list. This is the case
in your second example.

If you have more than one of those list-like arguments with an arbitrary
number of elements then you have to pass references instead or resort to
awkward workarounds like e.g. passing the number of elements as an
additional argument.

jue


------------------------------

Date: Thu, 18 Feb 2010 20:54:22 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <slrnhnrv41.t8n.tadmc@tadbox.sbcglobal.net>

Patrick Hartman <patrickh@gmail.com> wrote:
> Hi all, I was working on a program today and made a sub routine that I
> was passing a few scalars and also a hash to as arguments. This is
> what I initially tried:
>
> my %foo = qw(pepsi cola doctor pepper seven up);
> my $bar = 'soda is yummy!';
>
> &drink(%foo,$bar);
>
> sub drink {
>     my (%sodas,$opinion) = @_;

> The result was not what I was expecting. The $bar value that I was
> expecting to be the $opinion scalar ended up as a extra key in the
> %sodas hash as undef, and $opinion was empty.


> Is there a rule as to what order to pass types to a subroutine? 


Yes. Pass them in the "right" order :-)


> I'm a
> little confused on this one.


It appears that you have missed that

    Perl sees all arguments as one big, long, flat parameter list in @_

(from "perldoc perlsub")


So Perl sees:

    my (%sodas,$opinion) = ('pepsi',          'cola', 
                            'doctor',         'pepper' 
                            'seven',          'up', 
                            'soda is yummy!'
                           );

From that it should be easy to see why you got what you got.


-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"


------------------------------

Date: Thu, 18 Feb 2010 23:31:41 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <hll47u$36g$1@speranza.aioe.org>

On 2/18/2010 9:21 PM, Don Piven wrote:
> sln@netherlands.com wrote:
>> On Thu, 18 Feb 2010 16:43:38 -0800 (PST), Patrick Hartman
>> <patrickh@gmail.com> wrote:
>>
>> [snip]
>>
>>> Is there a rule as to what order to pass types to a subroutine? I'm a
>>> little confused on this one. Thanks,
>>>
>>> Patrick
>>
>> There is no rules in Perl, just syntax. If it doesen't work like
>> you expect, Perl has no way of knowing, and thinks that's what you
>> intend.
>> Use strict/warnings to help you out.
>>
>> Basically, I think this is what you did:
>>
>> my %sodas = (
>> # The never ending list
>> 'pepsi',
>> 'cola',
>> 'doctor',
>> 'pepper',
>> 'seven',
>> 'up',
>> 'soda is yummy!',
>> # Add to the never ending list
>> );
>
> Well, it would have been more like
>
> drink(qw(pepsi cola doctor pepper seven up), 'soda is yummy').
>
> That's seven arguments. Now when you do
>
> my (%sodas, $opinion) = @_ ;
>
> the %sodas hash is going to suck up all the items in the argument list,
> and leave nothing for $opinion, so 1) $opinion is going to be undef, and
> 2) the last argument is treated as a key, and since there are no more
> elements, that key gets a value of undef.
>
> Reversing the order of arguments ($opinion, %sodas) works because
> $opinion gets the first element of the list, and %sodas sucks down the
> rest of 'em in key/value order.
>
>> And, you should have gotten an "Odd number of elements ..."
>> type of message.
>
> That's a compile-time error, since the compiler has to know how many
> elements are in the initializer in order to know if it's an odd number.
> The compiler won't see a problem with %hash = @_ since it has no clue
> how long @_ is going to be.

no. it is not.

perl -We 'sub a { %_ = @_ } a(0)' -> warning
perl -e 'sub a { %_ = @_ } a(0)' -> nothing

-- 

   "Six by nine. Forty two."
   "That's it. That's all there is."
   "I always thought something was fundamentally wrong with the universe"


------------------------------

Date: Thu, 18 Feb 2010 23:44:20 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <87r5oheswr.fsf@quad.sysarch.com>

>>>>> "PH" == Patrick Hartman <patrickh@gmail.com> writes:

  PH> Hi all, I was working on a program today and made a sub routine that I
  PH> was passing a few scalars and also a hash to as arguments. This is
  PH> what I initially tried:

  PH> my %foo = qw(pepsi cola doctor pepper seven up);
  PH> my $bar = 'soda is yummy!';

  PH> &drink(%foo,$bar);

read perldoc perlsub. that isn't doing what you think it does. 

  PH> sub drink {
  PH>     my (%sodas,$opinion) = @_;

actually that is the bad line. the hash will slurp in all of @_ (and
should give you an odd count warning IF you used warnings which you
should do). nothing will ever be assigned to $opinion.

  PH> The result was not what I was expecting. The $bar value that I was
  PH> expecting to be the $opinion scalar ended up as a extra key in the
  PH> %sodas hash as undef, and $opinion was empty. I played around a little
  PH> and found that if I reverse the order so the scalar is passed before
  PH> the hash, it worked like I was hoping:

  PH> my %foo = qw(pepsi cola doctor pepper seven up);
  PH> my $bar = 'soda is yummy!';

  PH> &drink($bar,%foo);

  PH> sub drink {
  PH>     my ($opinion,%sodas) = @_;

  PH>     # do whatever here
  PH>     print "yummy!";
  PH> }

  PH> Is there a rule as to what order to pass types to a subroutine? I'm a
  PH> little confused on this one. Thanks,

no rule about order. just you the first array or hash in the left side
of any assignment gets all the rest of the values from the right
side. so if you must have one, it should be the last thing on the left
side. or use references to pass multiple aggregates around.

uri

-- 
Uri Guttman  ------  uri@stemsystems.com  --------  http://www.sysarch.com --
-----  Perl Code Review , Architecture, Development, Training, Support ------
---------  Gourmet Hot Cocoa Mix  ----  http://bestfriendscocoa.com ---------


------------------------------

Date: Thu, 18 Feb 2010 20:44:09 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: weird behavior when passing hashes to subroutine
Message-Id: <phh157xjmh.ln2@goaway.wombat.san-francisco.ca.us>

On 2010-02-19, Patrick Hartman <patrickh@gmail.com> wrote:
>
> &drink(%foo,$bar);

This is unrelated to your question, but important enough to point out:
don't call your subroutine with & unless you know why you need it.  It's
sufficient to call it as

drink(args);

Read perldoc perlsub for more details on the &.

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information



------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests. 

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 2825
***************************************


home help back first fref pref prev next nref lref last post