[32701] in Perl-Users-Digest
Perl-Users Digest, Issue: 3965 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 14 18:09:21 2013
Date: Fri, 14 Jun 2013 15:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 14 Jun 2013 Volume: 11 Number: 3965
Today's topics:
Re: Deep structure access and temp variable <hjp-usenet3@hjp.at>
Re: Deep structure access and temp variable <oneingray@gmail.com>
Re: Deep structure access and temp variable <ben@morrow.me.uk>
Re: Deep structure access and temp variable <jurgenex@hotmail.com>
Re: Deep structure access and temp variable (Tim McDaniel)
Re: Deep structure access and temp variable <derykus@gmail.com>
Re: Deep structure access and temp variable <rvtol+usenet@xs4all.nl>
Re: Deep structure access and temp variable <rweikusat@mssgmbh.com>
Re: Deep structure access and temp variable (Tim McDaniel)
Re: Deep structure access and temp variable <rweikusat@mssgmbh.com>
Re: Deep structure access and temp variable <derykus@gmail.com>
Re: Deep structure access and temp variable <rweikusat@mssgmbh.com>
Re: Deep structure access and temp variable <rweikusat@mssgmbh.com>
Re: Deep structure access and temp variable <derykus@gmail.com>
Re: Deep structure access and temp variable <ben@morrow.me.uk>
Re: Deep structure access and temp variable <rweikusat@mssgmbh.com>
Re: Deep structure access and temp variable <rweikusat@mssgmbh.com>
Re: Is there a better way than this? <ben@morrow.me.uk>
is valueclick the biggest perl biz use? <visphatesjava@gmail.com>
Re: Perl values interchangeability? <ben@morrow.me.uk>
Re: Perl values interchangeability? <peter@makholm.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 13 Jun 2013 22:51:44 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Deep structure access and temp variable
Message-Id: <slrnkrkc70.rsn.hjp-usenet3@hrunkner.hjp.at>
On 2013-06-13 16:06, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Adrien BARREAU <adrien.barreau@live.fr> wrote:
>>A simple question, but I have no clue about it:
>>
>># Version 1
>>my $A = $stuff->{a}{b}{c}{d}{e};
>>my $B = $stuff->{a}{b}{c}{d}{f};
>>my $C = $stuff->{a}{b}{c}{d}{g};
>>
>># Version 2
>>
>>my $tmp = $stuff->{a}{b}{c}{d};
>>my $A = $tmp->{e};
>>my $B = $tmp->{f};
>>my $C = $tmp->{g};
>>
>>What is the most efficient?
>
> Most efficient in regard to what? No, I'm not joking but I really mean
> it. I'm guessing you are referring to runtime but that is by no means
> the rule-it-all. Actually, if you program is so slow that you have to
> optimize on this micro-level, then you should look for a better
> algorithm or a different programming language.
Agreed (mostly).
> Having said that I would guess the runtime depends upon how large $tmp
> is. In version 2 you are creating a copy of the data.
$tmp is reference, so it's always the same size.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Thu, 13 Jun 2013 21:04:05 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <87y5adg1tm.fsf@violet.siamics.net>
>>>>> Adrien BARREAU <adrien.barreau@live.fr> writes:
[...]
> # Version 2
> my $tmp = $stuff->{a}{b}{c}{d};
> my $A = $tmp->{e};
> my $B = $tmp->{f};
> my $C = $tmp->{g};
> What is the most efficient? What appears to be the most idiomatic?
FWIW (and now that the experts have said their word), my
personal preference would be to write it as follows:
my $tmp = $stuff->{a}{b}{c}{d};
my ($A, $B, $C) = @$tmp{qw (e f g)};
[...]
--
FSF associate member #7257
------------------------------
Date: Thu, 13 Jun 2013 22:40:19 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Deep structure access and temp variable
Message-Id: <3rqp8a-dme2.ln1@anubis.morrow.me.uk>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Adrien BARREAU <adrien.barreau@live.fr> wrote:
> >
> >my $tmp = $stuff->{a}{b}{c}{d};
> >my $A = $tmp->{e};
> >my $B = $tmp->{f};
> >my $C = $tmp->{g};
> >
> >What is the most efficient?
[...]
>
> Having said that I would guess the runtime depends upon how large $tmp
> is.
$tmp is a reference, so it's as small as a Perl value can be (SV
overhead plus one 4- or 8-byte pointer).
Ben
------------------------------
Date: Thu, 13 Jun 2013 14:58:13 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <c0gkr89hcclkh24eajgos4311i6gega31i@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth J?Exner <jurgenex@hotmail.com>:
>> Adrien BARREAU <adrien.barreau@live.fr> wrote:
>> >
>> >my $tmp = $stuff->{a}{b}{c}{d};
>> >my $A = $tmp->{e};
>> >my $B = $tmp->{f};
>> >my $C = $tmp->{g};
>> >
>> >What is the most efficient?
>[...]
>>
>> Having said that I would guess the runtime depends upon how large $tmp
>> is.
>
>$tmp is a reference, so it's as small as a Perl value can be (SV
>overhead plus one 4- or 8-byte pointer).
Ahmm, well, aehhh, it goes against all my intuition, but you are right.
A reference by any other name is still a humble reference, even if the
referenced item is a gigantic data set.
I stand corrected.
jue
------------------------------
Date: Fri, 14 Jun 2013 00:11:57 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Deep structure access and temp variable
Message-Id: <kpdn4d$n1b$1@reader1.panix.com>
In article <87y5adg1tm.fsf@violet.siamics.net>,
Ivan Shmakov <oneingray@gmail.com> wrote:
> FWIW (and now that the experts have said their word), my
> personal preference would be to write it as follows:
>
>my $tmp = $stuff->{a}{b}{c}{d};
>my ($A, $B, $C) = @$tmp{qw (e f g)};
I had to write a test program and check "man perlref" to make sure it
parses OK. (I had been expecting $tmp{...} to be interpreted as a
hashref before @ was applied.) I would have written, and still
prefer, what I think is clearer:
my ($A, $B, $C) = @{$tmp}{qw (e f g)};
Pity that it does not permit $tmp->{qw (e f g)}, but man perlref says
that -> is for single-element access only.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 13 Jun 2013 23:05:20 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <kpebr2$70i$1@speranza.aioe.org>
On 6/13/2013 5:11 PM, Tim McDaniel wrote:
> In article <87y5adg1tm.fsf@violet.siamics.net>,
> Ivan Shmakov <oneingray@gmail.com> wrote:
>> FWIW (and now that the experts have said their word), my
>> personal preference would be to write it as follows:
>>
>> my $tmp = $stuff->{a}{b}{c}{d};
>> my ($A, $B, $C) = @$tmp{qw (e f g)};
>
> I had to write a test program and check "man perlref" to make sure it
> parses OK. (I had been expecting $tmp{...} to be interpreted as a
> hashref before @ was applied.) I would have written, and still
> prefer, what I think is clearer:
>
> my ($A, $B, $C) = @{$tmp}{qw (e f g)};
I suspect most would agree. And {} would be required anyway if the hash
ref is anything but a simple scalar.
A nice reference cheat sheet by Tye McQueen:
http://www.perlmonks.org/?node=References%20quick%20reference
>
> Pity that it does not permit $tmp->{qw (e f g)}, but man perlref says
> that -> is for single-element access only.
>
Lots agree including the cheat sheet author.
--
Charles DeRykus
------------------------------
Date: Fri, 14 Jun 2013 09:20:33 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Deep structure access and temp variable
Message-Id: <51bac441$0$15996$e4fe514c@news2.news.xs4all.nl>
On 14/06/2013 02:11, Tim McDaniel wrote:
> Ivan Shmakov <oneingray@gmail.com> wrote:
>> my ($A, $B, $C) = @$tmp{qw (e f g)};
>
> [..] I would have written, and still
> prefer, what I think is clearer:
>
> my ($A, $B, $C) = @{$tmp}{qw (e f g)};
Many styles possible. I like to write it as:
@{ $tmp }{qw/ e f g /};
One space before the first item and after the last, 2 spaces in between.
With qw, I often use the slash as separator, but () as well:
use POSIX qw(
nice
strftime
);
(and the imports in alphabetical order please :)
--
Ruud
------------------------------
Date: Fri, 14 Jun 2013 11:42:41 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <8738sldlcu.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 6/13/2013 5:11 PM, Tim McDaniel wrote:
>> In article <87y5adg1tm.fsf@violet.siamics.net>,
>> Ivan Shmakov <oneingray@gmail.com> wrote:
>>> FWIW (and now that the experts have said their word), my
>>> personal preference would be to write it as follows:
>>>
>>> my $tmp = $stuff->{a}{b}{c}{d};
>>> my ($A, $B, $C) = @$tmp{qw (e f g)};
>>
>> I had to write a test program and check "man perlref" to make sure it
>> parses OK. (I had been expecting $tmp{...} to be interpreted as a
>> hashref before @ was applied.) I would have written, and still
>> prefer, what I think is clearer:
>>
>> my ($A, $B, $C) = @{$tmp}{qw (e f g)};
>
> I suspect most would agree. And {} would be required anyway if the
> hash ref is anything but a simple scalar.
>
> A nice reference cheat sheet by Tye McQueen:
> http://www.perlmonks.org/?node=References%20quick%20reference
This is incomplete. It doesn't mention code references,
perl -e '$s = sub { print("What about me?\n") }; $s->();'
doesn't mention an important special-case about glob references/ <>,
perl -e 'my $fh; open($fh, "<", "/etc/services"); print <$fh>, "\n";'
versus
perl -e 'my $fh; open($fh, "<", "/etc/services"); print <{$fh}>, "\n";'
and the
If the reference is in a hash or an array (and you are getting
back a scalar), then you can drop the -> between the adjacent
[0] and/or {KEY} parts:
is inaccurate: Everything stored in a 'Perl container object' is a
scalar.
------------------------------
Date: Fri, 14 Jun 2013 14:29:38 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Deep structure access and temp variable
Message-Id: <kpf9ci$9h2$1@reader1.panix.com>
In article <8738sldlcu.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>doesn't mention an important special-case about glob references/ <>,
>
>perl -e 'my $fh; open($fh, "<", "/etc/services"); print <$fh>, "\n";'
>
>versus
>
>perl -e 'my $fh; open($fh, "<", "/etc/services"); print <{$fh}>, "\n";'
Or print <${fh}>
It would have been a kindness to explain the problem for those of us
who were unfamiliar with it. It took me a little while to find the
explanation.
"man perlop", towards the end of the I/O Operators section (in the
Perl version I checked):
If what the angle brackets contain is a simple scalar variable
(e.g., <$foo>), then that variable contains the name of the
filehandle to input from, or its typeglob, or a reference to
the same. For example:
$fh = \*STDIN;
$line = <$fh>;
If what's within the angle brackets is neither a filehandle nor
a simple scalar variable containing a filehandle name,
typeglob, or typeglob reference, it is interpreted as a
filename pattern to be globbed, and either a list of filenames
or the next filename in the list is returned, depending on
context. This distinction is determined on syntactic grounds
alone. That means "<$x>" is always a readline() from an
indirect handle, but "<$hash{key}>" is always a glob(). That's
because $x is a simple scalar variable, but $hash{key} is
not--it's a hash element. Even "<$x >" (note the extra space)
is treated as "glob("$x ")", not "readline($x)".
One level of double-quote interpretation is done first, but you
can't say "<$foo>" because that's an indirect filehandle as
explained in the previous paragraph. (In older versions of
Perl, programmers would insert curly brackets to force
interpretation as a filename glob: "<${foo}>". These days,
it's considered cleaner to call the internal function directly
as "glob($foo)", which is probably the right way to have done
it in the first place.)
So on this system,
>perl -e 'my $fh; open($fh, "<", "/etc/services"); print <$fh>, "\n";'
outputs the contents of the file /etc/services, but
>perl -e 'my $fh; open($fh, "<", "/etc/services"); print <{$fh}>, "\n";'
outputs one line,
GLOB(0xbb5061d0)
I didn't know that. Thank you.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 14 Jun 2013 15:42:21 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <87d2rog3ea.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <8738sldlcu.fsf@sapphire.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>doesn't mention an important special-case about glob references/ <>,
>>
>>perl -e 'my $fh; open($fh, "<", "/etc/services"); print <$fh>, "\n";'
>>
>>versus
>>
>>perl -e 'my $fh; open($fh, "<", "/etc/services"); print <{$fh}>, "\n";'
>
> Or print <${fh}>
>
> It would have been a kindness to explain the problem for those of us
> who were unfamiliar with it.
https://groups.google.com/forum/?hl=en-GB&fromgroups#!original/comp.lang.perl.misc/NcPfYj-gvi8/dSG-ORBMJ-wJ
?
------------------------------
Date: Fri, 14 Jun 2013 08:59:37 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <kpfela$8l0$1@speranza.aioe.org>
On 6/14/2013 3:42 AM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 6/13/2013 5:11 PM, Tim McDaniel wrote:
>>> In article <87y5adg1tm.fsf@violet.siamics.net>,
>>> Ivan Shmakov <oneingray@gmail.com> wrote:
>>>> FWIW (and now that the experts have said their word), my
>>>> personal preference would be to write it as follows:
>>>>
>>>> my $tmp = $stuff->{a}{b}{c}{d};
>>>> my ($A, $B, $C) = @$tmp{qw (e f g)};
>>>
>>> I had to write a test program and check "man perlref" to make sure it
>>> parses OK. (I had been expecting $tmp{...} to be interpreted as a
>>> hashref before @ was applied.) I would have written, and still
>>> prefer, what I think is clearer:
>>>
>>> my ($A, $B, $C) = @{$tmp}{qw (e f g)};
>>
>> I suspect most would agree. And {} would be required anyway if the
>> hash ref is anything but a simple scalar.
>>
>> A nice reference cheat sheet by Tye McQueen:
>> http://www.perlmonks.org/?node=References%20quick%20reference
>
> This is incomplete. It doesn't mention code references,
>
> perl -e '$s = sub { print("What about me?\n") }; $s->();'
>
> doesn't mention an important special-case about glob references/ <>,
>
> perl -e 'my $fh; open($fh, "<", "/etc/services"); print <$fh>, "\n";'
>
> versus
>
> perl -e 'my $fh; open($fh, "<", "/etc/services"); print <{$fh}>, "\n";'
The author reminds a commenter that the scope was 4 simple rules to
dereference "data structure references". He also clarifies:
I also didn't talk about creating references, symbolic references,
blessed references, closures, ref, UNIVERSAL::isa(), references to
globs, to the IO chunks of globs, to compiled regular expressions, nor
to any other types of things that Perl lets you have a reference to.
>
> and the
>
> If the reference is in a hash or an array (and you are getting
> back a scalar), then you can drop the -> between the adjacent
> [0] and/or {KEY} parts:
>
> is inaccurate: Everything stored in a 'Perl container object' is a
> scalar.
>
>
Yeah, I don't get the "getting back a scalar" part.
An example of the shortcut:
perl -e '@a=(["a","b"]);$r=\@a;print $r->[0][1]' ## vs. $r->[0]->[1]
But, it'd work in other cases too:
perl -le '@a=(["a",{b=>"c",d=>"e"}]);$r=\@a;
print $r->[0][1]{d}'
--
Charles DeRykus
------------------------------
Date: Fri, 14 Jun 2013 17:50:05 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <874nd0fxhe.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> perlref" to make sure it
>>>> parses OK. (I had been expecting $tmp{...} to be interpreted as a
>>>> hashref before @ was applied.) I would have written, and still
>>>> prefer, what I think is clearer:
>>>>
>>>> my ($A, $B, $C) = @{$tmp}{qw (e f g)};
>>>
>>> I suspect most would agree. And {} would be required anyway if the
>>> hash ref is anything but a simple scalar.
>>>
>>> A nice reference cheat sheet by Tye McQueen:
>>> http://www.perlmonks.org/?node=References%20quick%20reference
>>
>> This is incomplete. It doesn't mention code references,
>>
>> perl -e '$s = sub { print("What about me?\n") }; $s->();'
>>
>> doesn't mention an important special-case about glob references/ <>,
>>
>> perl -e 'my $fh; open($fh, "<", "/etc/services"); print <$fh>, "\n";'
>>
>> versus
>>
>> perl -e 'my $fh; open($fh, "<", "/etc/services"); print <{$fh}>, "\n";'
>
>
> The author reminds a commenter that
... all perceived shortcomings in his text are really intentional
omissions, at least in hindsight, lest he would have to admit that he
made some mistakes.
------------------------------
Date: Fri, 14 Jun 2013 20:33:37 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <87zjusebce.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Charles DeRykus <derykus@gmail.com> writes:
>> perlref" to make sure it
>>>>> parses OK. (I had been expecting $tmp{...} to be interpreted as a
>>>>> hashref before @ was applied.) I would have written, and still
>>>>> prefer, what I think is clearer:
>>>>>
>>>>> my ($A, $B, $C) = @{$tmp}{qw (e f g)};
>>>>
>>>> I suspect most would agree. And {} would be required anyway if the
>>>> hash ref is anything but a simple scalar.
>>>>
>>>> A nice reference cheat sheet by Tye McQueen:
>>>> http://www.perlmonks.org/?node=References%20quick%20reference
>>>
>>> This is incomplete. It doesn't mention code references,
>>>
>>> perl -e '$s = sub { print("What about me?\n") }; $s->();'
>>>
>>> doesn't mention an important special-case about glob references/ <>,
>>>
>>> perl -e 'my $fh; open($fh, "<", "/etc/services"); print <$fh>, "\n";'
>>>
>>> versus
>>>
>>> perl -e 'my $fh; open($fh, "<", "/etc/services"); print <{$fh}>, "\n";'
>>
>>
>> The author reminds a commenter that
>
> ... all perceived shortcomings in his text are really intentional
> omissions, at least in hindsight, lest he would have to admit that he
> made some mistakes.
In case this seems overly cryptic: Perl doesn't have 'data structures'
it has various kinds of objects and references to objects. This means
unless the author provides a definition of 'data structures' in the
context of Perl, a reader has to guess what was meant by that and
guessing that it was supposed to mean 'objects' isn't very far
fetched.
Leaving this aside, this 'cheat sheet' is a partially erroneous
paraphrase of the 'Using references' section of the perlref manpage:
1. Anywhere you'd put an identifier (or chain of identifiers)
as part of a variable or subroutine name, you can replace
the identifier with a simple scalar variable containing a
reference of the correct type:
[...]
2. Anywhere you'd put an identifier (or chain of identifiers)
as part of a variable or subroutine name, you can replace
the identifier with a BLOCK returning a reference of the
correct type.
[...]
3. Subroutine calls and lookups of individual array elements
arise often enough that it gets cumbersome to use
method 2. As a form of syntactic sugar, the examples
for method 2 may be written:
$arrayref->[0] = "January"; # Array element
[...]
The arrow is optional between brackets subscripts
This is not only complete and correct but also (IMHO) no more
difficult to understand than the other text.
------------------------------
Date: Fri, 14 Jun 2013 13:21:43 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <kpfu0n$l23$1@speranza.aioe.org>
On 6/14/2013 12:33 PM, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> Charles DeRykus <derykus@gmail.com> writes:
>>> perlref" to make sure it
>>>>>> parses OK. (I had been expecting $tmp{...} to be interpreted as a
>>>>>> hashref before @ was applied.) I would have written, and still
>>>>>> prefer, what I think is clearer:
>>>>>>
>>>>>> my ($A, $B, $C) = @{$tmp}{qw (e f g)};
>>>>>
>>>>> I suspect most would agree. And {} would be required anyway if the
>>>>> hash ref is anything but a simple scalar.
>>>>>
>>>>> A nice reference cheat sheet by Tye McQueen:
>>>>> http://www.perlmonks.org/?node=References%20quick%20reference
>>>>
>>>> This is incomplete. It doesn't mention code references,
>>>>
>>>> perl -e '$s = sub { print("What about me?\n") }; $s->();'
>>>>
>>>> doesn't mention an important special-case about glob references/ <>,
>>>>
>>>> perl -e 'my $fh; open($fh, "<", "/etc/services"); print <$fh>, "\n";'
>>>>
>>>> versus
>>>>
>>>> perl -e 'my $fh; open($fh, "<", "/etc/services"); print <{$fh}>, "\n";'
>>>
>>>
>>> The author reminds a commenter that
>>
>> ... all perceived shortcomings in his text are really intentional
>> omissions, at least in hindsight, lest he would have to admit that he
>> made some mistakes.
>
> In case this seems overly cryptic: Perl doesn't have 'data structures'
> it has various kinds of objects and references to objects. This means
> unless the author provides a definition of 'data structures' in the
> context of Perl, a reader has to guess what was meant by that and
> guessing that it was supposed to mean 'objects' isn't very far
> fetched.
>
> Leaving this aside, this 'cheat sheet' is a partially erroneous
> paraphrase of the 'Using references' section of the perlref manpage:
>
> 1. Anywhere you'd put an identifier (or chain of identifiers)
> as part of a variable or subroutine name, you can replace
> the identifier with a simple scalar variable containing a
> reference of the correct type:
>
> [...]
>
>
> 2. Anywhere you'd put an identifier (or chain of identifiers)
> as part of a variable or subroutine name, you can replace
> the identifier with a BLOCK returning a reference of the
> correct type.
>
> [...]
>
> 3. Subroutine calls and lookups of individual array elements
> arise often enough that it gets cumbersome to use
> method 2. As a form of syntactic sugar, the examples
> for method 2 may be written:
>
> $arrayref->[0] = "January"; # Array element
>
> [...]
>
> The arrow is optional between brackets subscripts
>
> This is not only complete and correct but also (IMHO) no more
> difficult to understand than the other text.
>
Tye's cheat sheet dates from 2001 and still provides a short, useful
guide. He carefully qualified its scope. You could comment/critique
Tye's page fully on that forum and/or publish your own as as updated,
improved version.
--
Charles DeRykus
------------------------------
Date: Fri, 14 Jun 2013 21:51:37 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Deep structure access and temp variable
Message-Id: <pbcs8a-3gh.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> > Charles DeRykus <derykus@gmail.com> writes:
> >> [Rainer wrote:]
> >>> [Charles (IIRC?) wrote:]
> >>>>
> >>>> A nice reference cheat sheet by Tye McQueen:
> >>>> http://www.perlmonks.org/?node=References%20quick%20reference
> >>>
> >>> This is incomplete. It doesn't mention code references,
> >>
> >> The author reminds a commenter that
> >
> > ... all perceived shortcomings in his text are really intentional
> > omissions, at least in hindsight, lest he would have to admit that he
> > made some mistakes.
>
> In case this seems overly cryptic: Perl doesn't have 'data structures'
> it has various kinds of objects and references to objects. This means
> unless the author provides a definition of 'data structures' in the
> context of Perl, a reader has to guess what was meant by that and
> guessing that it was supposed to mean 'objects' isn't very far
> fetched.
Do you ever get tired of being snide, pedantic and somewhat unpleasant?
Perl has data structures. They are the things described in perldsc, the
Perl Data Structures Cookbook. Perl also has objects, which are
something rather different, and are not covered in Tye's tutorial.
Ben
------------------------------
Date: Fri, 14 Jun 2013 22:11:58 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <87sj0ke6sh.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> > Charles DeRykus <derykus@gmail.com> writes:
>> >> [Rainer wrote:]
>> >>> [Charles (IIRC?) wrote:]
>> >>>>
>> >>>> A nice reference cheat sheet by Tye McQueen:
>> >>>> http://www.perlmonks.org/?node=References%20quick%20reference
>> >>>
>> >>> This is incomplete. It doesn't mention code references,
>> >>
>> >> The author reminds a commenter that
>> >
>> > ... all perceived shortcomings in his text are really intentional
>> > omissions, at least in hindsight, lest he would have to admit that he
>> > made some mistakes.
>>
>> In case this seems overly cryptic: Perl doesn't have 'data structures'
>> it has various kinds of objects and references to objects. This means
>> unless the author provides a definition of 'data structures' in the
>> context of Perl, a reader has to guess what was meant by that and
>> guessing that it was supposed to mean 'objects' isn't very far
>> fetched.
>
> Do you ever get tired of being snide, pedantic and somewhat
> unpleasant?
>
> Perl has data structures. They are the things described in perldsc, the
> Perl Data Structures Cookbook. Perl also has objects, which are
> something rather different, and are not covered in Tye's tutorial.
"Tye's tutorial" is a bad rehash of a perl man page. Did it already
occur to you that you're implicitly trashing the guy who wrote the
more useful text?
------------------------------
Date: Fri, 14 Jun 2013 22:16:52 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <87obb8e6kb.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> > Charles DeRykus <derykus@gmail.com> writes:
>> >> [Rainer wrote:]
>> >>> [Charles (IIRC?) wrote:]
>> >>>>
>> >>>> A nice reference cheat sheet by Tye McQueen:
>> >>>> http://www.perlmonks.org/?node=References%20quick%20reference
>> >>>
>> >>> This is incomplete. It doesn't mention code references,
>> >>
>> >> The author reminds a commenter that
>> >
>> > ... all perceived shortcomings in his text are really intentional
>> > omissions, at least in hindsight, lest he would have to admit that he
>> > made some mistakes.
>>
>> In case this seems overly cryptic: Perl doesn't have 'data structures'
>> it has various kinds of objects and references to objects. This means
>> unless the author provides a definition of 'data structures' in the
>> context of Perl, a reader has to guess what was meant by that and
>> guessing that it was supposed to mean 'objects' isn't very far
>> fetched.
>
> Do you ever get tired of being snide, pedantic and somewhat
> unpleasant?
To answer that question: One reason why I'm on USENET is because I'm
interested in discussing things. Unfortunately, many USENET
'discussions' don't really qualify for that but people who are more
into throwing bottles at others in order to express their discontent
with them (something which happened to me yesterday evening) at least
can't really do that.
------------------------------
Date: Thu, 13 Jun 2013 23:12:27 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Is there a better way than this?
Message-Id: <bnsp8a-b4f2.ln1@anubis.morrow.me.uk>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Tue, 11 Jun 2013 00:15:19 +0100, Ben Morrow wrote:
>
> > Quoth tmcd@panix.com:
> >> In article <qr5h8a-v4h.ln1@anubis.morrow.me.uk>,
> >>
> >> return EXPR
> >>
> >> doesn't say LIST, but you say it's a list operator, and that makes ense
> >> because it can return lists.
> >
> > That's interesting, actually. For starters, the perlfunc entry is
> > definitely wrong: regardless of the eventual context return gives to its
> > arguments, it always parses as a list operator.
>
> Nope, it doesn't say anything about how it parses, but how it evaluates,
> and that is correct (on my 5.14):
Well, perlfunc isn't explicit about its terms, but in pretty-much all
the other cases any argument that isn't written as LIST is a single
value evaluated in scalar context.
I wasn't talking about the description, which is correct, but about the
use of
return EXPR
rather than
return LIST
Ben
------------------------------
Date: Fri, 14 Jun 2013 10:37:23 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: is valueclick the biggest perl biz use?
Message-Id: <2af8b6bd-a31c-4f44-9a8e-82421b4d3eb5@googlegroups.com>
wondering what some really big perl in e commerce shops?
------------------------------
Date: Thu, 13 Jun 2013 23:06:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl values interchangeability?
Message-Id: <5csp8a-b4f2.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> >> my $c = $b + 0; # $b was /interpreted/ as a number, yet still a string
>
> > Nope. $b is now also POK and IOK, so the bitwise ops will now treat
> > it as a number. (This is why it was a bug for them to make the
> > string/number distinction in the first place: Perl just doesn't
> > preserve that information.)
>
> ! That was, for the lack of a better word, unexpected.
Then you have the wrong mental model of how Perl values work. 'String'
and 'number' are not well-defined types in Perl, not even dynamic types
like 'string' and 'reference'. Perl will convert between string, signed
integer, unsigned integer and float as it sees fit, and cache the
conversions wherever possible.
> > All undefined values are equal,
> > at the Perl level at least.
>
> ... Moreover, an application may choose to use undef as an
> "unknown" value. Thus: same ($a, undef) == same (undef, $b) ==
> same (undef, undef) == undef. (Although it's not the behavior
> I'm interested in in this case.)
I'm not sure where you're quoting that from, nor why... Perl's undef is
not the same as SQL's NULL. All undefined values are equivalent.
> >> And how do I check for these (and especially the tied values)?
>
> > For tied values, tied (). For overloaded objects, see the overload
> > documentation; however you've already rejected refs above, so you
> > won't see objects of any kind.
>
> To clarify it, the predicate above was intended to be used for
> the "simple" values only, and be combined with same_ref () below
> if necessary.
>
> > There are other kinds of magic, but they're rare and probably not
> > worth worrying about.
>
> Curiously, is $! one of them? FWIW, while Scalar::Util(3)
> states that it's a tied scalar, tied ($!) is undef.
$! is magic, but not because it's a dualvar. It's magic because it's
linked to C's errno, such that changing one changes the other to match.
(It's actually impossible to set $! to an arbitrary string; you just end
up setting errno to 0, which sets the string part of $! to the empty
string.)
I think all the special punctuation variables are magic. Other values
that are magic are, for instance, the lvalue returned by substr(), pos()
and vec(), @ISA, %ENV and %SIG, and the hashes used to hold the symbol
table.
> > If you're testing for identity (are these the same object?) then
> > refaddr is necessary and sufficient.
>
> ... I wonder if it's codified somewhere in the documentation?
> I understand that on a J. von Neumann architecture there's
> hardly any other sensible way to implement Perl's objects and
> references, yet...
I don't think so. Note also that on a threaded perl objects will change
refaddr when you start a new thread.
Ben
------------------------------
Date: Fri, 14 Jun 2013 09:05:02 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: Perl values interchangeability?
Message-Id: <87ehc59nq9.fsf@vps1.hacking.dk>
Ben Morrow <ben@morrow.me.uk> writes:
> It's usual in Perl to treat the string value as 'canonical'. Objects or
> values which have the same string value but are in some important way
> 'different' are basically breaking the rules.
I am not sure where you got that rule from. I would never assume that
the stringification of objects follows any other rule that "Whatever
makes most sense for presentation to a User".
This might define sensible equivalence classes, but I would never
assume that it would give me referential equality (use refaddr) or a
strict value equality (use Test::Deep::NoTest).
//Makholm
------------------------------
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 3965
***************************************
