[31633] in Perl-Users-Digest
Perl-Users Digest, Issue: 2896 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 30 21:09:32 2010
Date: Tue, 30 Mar 2010 18:09:13 -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 Tue, 30 Mar 2010 Volume: 11 Number: 2896
Today's topics:
Re: equivalent <justin.1003@purestblue.com>
Re: equivalent <sreservoir@gmail.com>
Re: equivalent <sreservoir@gmail.com>
Re: equivalent <ben@morrow.me.uk>
Re: equivalent <ben@morrow.me.uk>
Re: equivalent <ben@morrow.me.uk>
Re: equivalent <sreservoir@gmail.com>
Re: equivalent <tadmc@seesig.invalid>
Re: equivalent <sreservoir@gmail.com>
Re: equivalent <sreservoir@gmail.com>
Re: File formatting <nickli2000@gmail.com>
Re: Text::ParseWords sln@netherlands.com
Re: the mug of Perl <ben@morrow.me.uk>
Re: the mug of Perl <john@castleamber.com>
Re: the mug of Perl <jurgenex@hotmail.com>
Re: the mug of Perl <john@castleamber.com>
Re: the mug of Perl <ben@morrow.me.uk>
Re: the mug of Perl <justin.1003@purestblue.com>
Re: the mug of Perl <rvtol+usenet@xs4all.nl>
Re: unary minus strangeness <blgl@hagernas.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 30 Mar 2010 22:10:59 +0100
From: Justin C <justin.1003@purestblue.com>
Subject: Re: equivalent
Message-Id: <306a87-npc.ln1@purestblue.com>
In article <h44887-vcl.ln1@osiris.mauzo.dyndns.org>, Ben Morrow wrote:
>
> Quoth sreservoir <sreservoir@gmail.com>:
>> On 3/29/2010 6:00 PM, RedGrittyBrick wrote:
>> > Dr.Ruud wrote:
>> >> RedGrittyBrick wrote:
>> >>
>> >>> my $query = new CGI;
>> >>
>> >> ITYM:
>> >>
>> >> my $cgi = CGI::->new();
>> >>
>> >
>> > Yes, I did hesitate over that. In the end I copied what is in the
>> > documentation http://perldoc.perl.org/CGI.html#PROGRAMMING-STYLE.
>> >
>> > I've actually forgotten the pitfalls of the, er, deprecated syntax.
>> > Perusing perlobj, perlboot and perltoot didn't help me (though I wasn't
>> > very thorough). Is it anything to do with naming your constructor shazam
>> > and writing `my $instance = shazam OddObject'. Though it works,
>> > presumably as intended, I guess that sort of thing can confuse people &
>> > perl?
>> >
>> > So, why is `CGI::->new()' preferred over `CGI->new()' preferred over
>> > `new CGI()'?
>>
>> it isn't, unless someone's stupid enough to make &new or &CGI. it's
>> just less ambiguous:
>
> Having a 'sub new' in scope is not uncommon:
>
> package Foo;
>
> sub new { ... }
>
> sub init { my $x = CGI->new(...) }
>
> 1;
>
>> new CGI chokes if there is a &new or a &CGI.
>
> Not if you do it properly, that is
>
> new CGI ();
>
> rather than a bare
>
> new CGI;
>
> The latter is a little too ambiguous even for Perl.
>
>> CGI->new chokes if there is a &CGI. might do bad things if CGI isn't
>> require'd or use'd.
>
> You mean 'if the CGI->new method isn't defined'.
>
>> 'CGI'->new almost always does the right thing.
>
> use IO::Handle;
> warn "STDOUT"->blocking;
>
> Yes, this is 'the right thing' in this case, but not always. Just don't
> open a filehandle called 'CGI'.
>
>> CGI::->new is syntactic sugar for 'CGI'->new.
>
> For CGI->new, except it ignores any 'sub CGI'.
>
> Ben
Well thanks a whole *huge* bunch, guys. Just when I start thinking I'm
starting to understand what I'm doing you go and confuse the hell out of
me! I spend a lot of my time in this group reading that I should refer
to documentation, and then you go and contradict the damn documentation!
OK, I accept that the module documentation isn't Perl documentation, but
that's a heavily used module, and it says quite clearly (unless I need
to update it):
use CGI;
$q = new CGI;
print $q->header, ....
If you can't explain it to me simply can you point me to some docs... I
see a Catch 22 here.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Tue, 30 Mar 2010 18:50:10 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: equivalent
Message-Id: <hotv78$8t4$1@speranza.aioe.org>
On 3/29/2010 10:19 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir@gmail.com>:
>> On 3/29/2010 6:23 PM, Dr.Ruud wrote:
>>>
>>> perl -MData::Dumper -MCGI -wle'
>>> sub new { die "in new" }
>>> sub CGI { die "in CGI" }
>>> my $cgi = CGI::->new;
>>> print Dumper $cgi;
>>> '
>>>
>>> $VAR1 = bless( {
>>> '.parameters' => [],
>>> '.charset' => 'ISO-8859-1',
>>> '.fieldnames' => {},
>>> 'escape' => 1
>>> }, 'CGI' );
>>
>> this is horribly contrived and should never happen. but yes, this is
>> a case where ::-> is preferred.
>
> perldoc aliased.
No documentation found for "aliased".
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe."
------------------------------
Date: Tue, 30 Mar 2010 19:04:01 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: equivalent
Message-Id: <hou017$a6o$1@speranza.aioe.org>
On 3/29/2010 10:26 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir@gmail.com>:
>> On 3/29/2010 6:00 PM, RedGrittyBrick wrote:
>>> Dr.Ruud wrote:
>>>> RedGrittyBrick wrote:
>>>>
>>>>> my $query = new CGI;
>>>>
>>>> ITYM:
>>>>
>>>> my $cgi = CGI::->new();
>>>>
>>>
>>> Yes, I did hesitate over that. In the end I copied what is in the
>>> documentation http://perldoc.perl.org/CGI.html#PROGRAMMING-STYLE.
>>>
>>> I've actually forgotten the pitfalls of the, er, deprecated syntax.
>>> Perusing perlobj, perlboot and perltoot didn't help me (though I wasn't
>>> very thorough). Is it anything to do with naming your constructor shazam
>>> and writing `my $instance = shazam OddObject'. Though it works,
>>> presumably as intended, I guess that sort of thing can confuse people&
>>> perl?
>>>
>>> So, why is `CGI::->new()' preferred over `CGI->new()' preferred over
>>> `new CGI()'?
>>
>> it isn't, unless someone's stupid enough to make&new or&CGI. it's
>> just less ambiguous:
>
> Having a 'sub new' in scope is not uncommon:
>
> package Foo;
>
> sub new { ... }
>
> sub init { my $x = CGI->new(...) }
>
> 1;
I haven't written an OO module for a long time, so this possibility
slipped my mind. however:
% perl -MCGI -E 'sub new { die "wrong new" } say new CGI'
CGI=HASH(0x86f882c)
>> new CGI chokes if there is a&new or a&CGI.
>
> Not if you do it properly, that is
>
> new CGI ();
>
> rather than a bare
>
> new CGI;
>
> The latter is a little too ambiguous even for Perl.
fair enough. actually, I don't like that much either.
>> CGI->new chokes if there is a&CGI. might do bad things if CGI isn't
>> require'd or use'd.
>
> You mean 'if the CGI->new method isn't defined'.
% perl -MCGI -MIO::Handle -E'sub CGI { IO::Handle:: } say CGI->new'
IO::Handle=GLOB(0x9ac1a20)
I mean exactly what I said.
but yes, it will also choke if CGI can't new.
>> 'CGI'->new almost always does the right thing.
>
> use IO::Handle;
> warn "STDOUT"->blocking;
>
> Yes, this is 'the right thing' in this case, but not always. Just don't
> open a filehandle called 'CGI'.
"almost"; in any case, none of the others would help you much if you did
have *CGI{IO}.
>> CGI::->new is syntactic sugar for 'CGI'->new.
>
> For CGI->new, except it ignores any 'sub CGI'.
actually, both seem to be syntactic sugar for 'CGI'->, except CGI->
does call a function if it exists.
% perl -MO=Deparse -e 'CGI::->new'
'CGI'->new;
-e syntax OK
% perl -MO=Deparse -e 'CGI->new'
'CGI'->new;
-e syntax OK
% perl -MO=Deparse -e 'new CGI'
'CGI'->new;
-e syntax OK
% perl -MO=Deparse -e 'new CGI ()'
'CGI'->new;
-e syntax OK
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe."
------------------------------
Date: Wed, 31 Mar 2010 00:28:37 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: equivalent
Message-Id: <52ea87-2m51.ln1@osiris.mauzo.dyndns.org>
Quoth Justin C <justin.1003@purestblue.com>:
>
> Well thanks a whole *huge* bunch, guys. Just when I start thinking I'm
> starting to understand what I'm doing you go and confuse the hell out of
> me! I spend a lot of my time in this group reading that I should refer
> to documentation, and then you go and contradict the damn documentation!
I apologise (somewhat). I was being something of a smartass, which while
generally expected on Usenet is less than helpful to those trying to
learn the language. (The group isn't solely (or even mostly) for their
benefit, of course.)
> OK, I accept that the module documentation isn't Perl documentation, but
> that's a heavily used module, and it says quite clearly (unless I need
> to update it):
>
> use CGI;
> $q = new CGI;
> print $q->header, ....
>
> If you can't explain it to me simply can you point me to some docs... I
> see a Catch 22 here.
Method calls like
new Class;
method $object;
method $object @args; # note the lack of comma after $object
are in a form usually called 'indirect object syntax'[0]. This was added
into Perl when objects were first introduced (5.000, I believe), with
the intention of allowing calls like
new CGI;
that look like C++ constructors and
ungetc $FH "foo";
that look like builtins like 'print'. It's generally considered nowadays
that this syntax was a bad idea, mostly because it's not clear whether
new CGI;
is equivalent to
new(CGI());
or to
CGI->new();
and Perl won't always pick the one you expect[1]. Quite a lot of
documentation from the early days of Perl OO (and CGI.pm was one of the
first OO modules) was written with the old style. and hasn't been
updated. The translation is simple: when you see something like
METHOD INVOCANT ARGS;
you instead use
INVOCANT->METHOD(ARGS);
(My copy of CGI.pm (3.43) has the new style in the SYNOPSIS at the top,
and then multiple instances of the old style in the body of the docs.)
Ben
[0] As tchrist pointed out on p5p, 'indirect object syntax' is a
complete misnomer, resulting from a misunderstanding of the term
'indirect object slot' as applied to functions like 'print'. In an
expression like
print { which_fh() } "foo";
the {} block is an 'indirect object' not because of where it is placed
syntactically but because, rather than being an object (in this case a
filehandle) 'directly', it is an expression that returns one. A better
term would be 'dative method syntax'.
[1] The main point of my post was that
CGI->new
won't always do what you expect either. Bareword parsing in Perl is
*scary*. As a general rule of thumb, make sure to never create a
package, a sub, or a (global bareword) filehandle with the same name as
one of the other two. The convention that sub names look_like_this,
package names LookLikeThis and filehandles LOOK_LIKE_THIS helps here,
though there are enough exceptions to be worrying. This is also (yet
another) reason to avoid global bareword filehandles in favour of
lexicals.
------------------------------
Date: Wed, 31 Mar 2010 00:34:43 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: equivalent
Message-Id: <jdea87-2m51.ln1@osiris.mauzo.dyndns.org>
Quoth sreservoir <sreservoir@gmail.com>:
> On 3/29/2010 10:19 PM, Ben Morrow wrote:
> >
> > perldoc aliased.
>
> No documentation found for "aliased".
Well, no. It's a CPAN module, quite commonly used in some circles, which
allows you to say
use aliased "Some::Silly::Long::Class::Name" => "SomeClass";
my $x = SomeClass->new;
It works by exporting a 'sub SomeClass' into the current package that
simply returns the string "Some::Silly::Long::Class::Name", and relies
on the fact that Perl will pick a sub over a package for a bareword if
one exists. I find the whole concept makes me uneasy, especially since
once you've said
package Foo;
use aliased "Some::Class" => "SomeClass";
you've effectively stomped on Foo::SomeClass from the point of view of
the rest of the program.
Ben
------------------------------
Date: Wed, 31 Mar 2010 01:00:14 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: equivalent
Message-Id: <etfa87-1861.ln1@osiris.mauzo.dyndns.org>
Quoth sreservoir <sreservoir@gmail.com>:
> On 3/29/2010 10:26 PM, Ben Morrow wrote:
> >
> > Having a 'sub new' in scope is not uncommon:
> >
> > package Foo;
> >
> > sub new { ... }
> >
> > sub init { my $x = CGI->new(...) }
> >
> > 1;
>
> I haven't written an OO module for a long time, so this possibility
> slipped my mind. however:
>
> % perl -MCGI -E 'sub new { die "wrong new" } say new CGI'
> CGI=HASH(0x86f882c)
There is no other possible interpretation for the bareword CGI here. If
you also had a 'sub CGI' you would get new(CGI()) rather than
CGI()->new(). Also, if you were calling 'method $object' rather than
'method Class' and there was a 'sub method' in scope you would get the
sub call.
> >> CGI->new chokes if there is a&CGI. might do bad things if CGI isn't
> >> require'd or use'd.
> >
> > You mean 'if the CGI->new method isn't defined'.
>
> % perl -MCGI -MIO::Handle -E'sub CGI { IO::Handle:: } say CGI->new'
> IO::Handle=GLOB(0x9ac1a20)
>
> I mean exactly what I said.
I was responding to 'might do bad things if...'.
~% perl -e'sub CGI::new { warn "CGI->new" } CGI->new'
CGI->new at -e line 1.
No require or use there. The case where it does make a difference is
(ironically) with the 'new CGI' syntax, where the presence of a 'require
CGI' or 'use CGI' will prime the parser to try and make CGI into a
classname rather than something else.
> >> 'CGI'->new almost always does the right thing.
> >
> > use IO::Handle;
> > warn "STDOUT"->blocking;
> >
> > Yes, this is 'the right thing' in this case, but not always. Just don't
> > open a filehandle called 'CGI'.
>
> "almost"; in any case, none of the others would help you much if you did
> have *CGI{IO}.
Fair enough; also true. I don't believe there's any way to force
interpretation as a class rather than a filehandle.
> >> CGI::->new is syntactic sugar for 'CGI'->new.
> >
> > For CGI->new, except it ignores any 'sub CGI'.
>
> actually, both seem to be syntactic sugar for 'CGI'->, except CGI->
> does call a function if it exists.
Well, both CGI:: and CGI-where-we-expect-a-classname are simply
exceptions to strict 'subs' (which actually prevents barewords from
being treated as unquoted strings, and has nothing to do with subs).
However, CGI->new and "CGI"->new are at least slightly different:
~% perl -MO=Concise -e'CGI->new'
7 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v:{ ->3
6 <1> entersub[t1] vKS/TARG ->7
3 <0> pushmark s ->4
4 <$> const(PV "CGI") sM/BARE ->5
5 <$> method_named(PV "new") ->6
-e syntax OK
~% perl -MO=Concise -e'"CGI"->new'
7 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v:{ ->3
6 <1> entersub[t1] vKS/TARG ->7
3 <0> pushmark s ->4
4 <$> const(PV "CGI") sM ->5
5 <$> method_named(PV "new") ->6
-e syntax OK
I don't know whether that extra '/BARE' makes any difference, though.
Ben
------------------------------
Date: Tue, 30 Mar 2010 20:19:28 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: equivalent
Message-Id: <hou4en$goo$1@speranza.aioe.org>
On 3/30/2010 7:34 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir@gmail.com>:
>> On 3/29/2010 10:19 PM, Ben Morrow wrote:
>>>
>>> perldoc aliased.
>>
>> No documentation found for "aliased".
>
> Well, no. It's a CPAN module, quite commonly used in some circles, which
> allows you to say
>
> use aliased "Some::Silly::Long::Class::Name" => "SomeClass";
>
> my $x = SomeClass->new;
>
> It works by exporting a 'sub SomeClass' into the current package that
> simply returns the string "Some::Silly::Long::Class::Name", and relies
> on the fact that Perl will pick a sub over a package for a bareword if
> one exists. I find the whole concept makes me uneasy, especially since
> once you've said
>
> package Foo;
> use aliased "Some::Class" => "SomeClass";
>
> you've effectively stomped on Foo::SomeClass from the point of view of
> the rest of the program.
I suppose you could use some caller shenanigans with a closure, but.
sub foo($$) {
my $caller = caller;
my $aliased = shift;
my $package = shift;
*$aliased = sub () {
((caller)->isa($caller))? $package : $aliased;
}
}
of course, I don't understand what is so difficult about:
$this = that::;
$this->foo;
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe."
------------------------------
Date: Tue, 30 Mar 2010 19:33:15 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: equivalent
Message-Id: <slrnhr55qn.n97.tadmc@tadbox.sbcglobal.net>
Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Justin C <justin.1003@purestblue.com>:
>> $q = new CGI;
> Method calls like
>
> new Class;
> method $object;
> method $object @args; # note the lack of comma after $object
>
> are in a form usually called 'indirect object syntax'[0]. This was added
> into Perl when objects were first introduced (5.000, I believe),
OP should see the docs section "Indirect Object Syntax" in perlobj.pod.
But it contradicts Ben too:
The other way to invoke a method is by using the so-called "indirect
object" notation. This syntax was available in Perl 4 long before
objects were introduced...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Tue, 30 Mar 2010 20:37:29 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: equivalent
Message-Id: <hou5gf$i85$1@speranza.aioe.org>
On 3/30/2010 8:00 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir@gmail.com>:
>> On 3/29/2010 10:26 PM, Ben Morrow wrote:
>>>
>>> Having a 'sub new' in scope is not uncommon:
>>>
>>> package Foo;
>>>
>>> sub new { ... }
>>>
>>> sub init { my $x = CGI->new(...) }
>>>
>>> 1;
>>
>> I haven't written an OO module for a long time, so this possibility
>> slipped my mind. however:
>>
>> % perl -MCGI -E 'sub new { die "wrong new" } say new CGI'
>> CGI=HASH(0x86f882c)
>
> There is no other possible interpretation for the bareword CGI here. If
> you also had a 'sub CGI' you would get new(CGI()) rather than
> CGI()->new(). Also, if you were calling 'method $object' rather than
> 'method Class' and there was a 'sub method' in scope you would get the
> sub call.
fair enough.
>>>> CGI->new chokes if there is a&CGI. might do bad things if CGI isn't
>>>> require'd or use'd.
>>>
>>> You mean 'if the CGI->new method isn't defined'.
>>
>> % perl -MCGI -MIO::Handle -E'sub CGI { IO::Handle:: } say CGI->new'
>> IO::Handle=GLOB(0x9ac1a20)
>>
>> I mean exactly what I said.
>
> I was responding to 'might do bad things if...'.
>
> ~% perl -e'sub CGI::new { warn "CGI->new" } CGI->new'
> CGI->new at -e line 1.
>
> No require or use there. The case where it does make a difference is
> (ironically) with the 'new CGI' syntax, where the presence of a 'require
> CGI' or 'use CGI' will prime the parser to try and make CGI into a
> classname rather than something else.
typically, you shouldn't define stuff int the namespace of a standard
module. contrived counterexample, though, I suppose.
>>>> 'CGI'->new almost always does the right thing.
>>>
>>> use IO::Handle;
>>> warn "STDOUT"->blocking;
>>>
>>> Yes, this is 'the right thing' in this case, but not always. Just don't
>>> open a filehandle called 'CGI'.
>>
>> "almost"; in any case, none of the others would help you much if you did
>> have *CGI{IO}.
>
> Fair enough; also true. I don't believe there's any way to force
> interpretation as a class rather than a filehandle.
this is, incidentally, slightly ridiculous.
% perl -E'sub STDOUT::a { die "right blocking" }
say((*{STDOUT}{PACKAGE})->blocking);'
Can't locate object method "blocking" via package "main" at -e line 2.
um.
>>>> CGI::->new is syntactic sugar for 'CGI'->new.
>>>
>>> For CGI->new, except it ignores any 'sub CGI'.
>>
>> actually, both seem to be syntactic sugar for 'CGI'->, except CGI->
>> does call a function if it exists.
>
> Well, both CGI:: and CGI-where-we-expect-a-classname are simply
> exceptions to strict 'subs' (which actually prevents barewords from
> being treated as unquoted strings, and has nothing to do with subs).
> However, CGI->new and "CGI"->new are at least slightly different:
I suppose it should be clarified that I meant it's syntactic sugar only
in the 'suppose it's a classname' case.
> ~% perl -MO=Concise -e'CGI->new'
> 7<@> leave[1 ref] vKP/REFC ->(end)
> 1<0> enter ->2
> 2<;> nextstate(main 1 -e:1) v:{ ->3
> 6<1> entersub[t1] vKS/TARG ->7
> 3<0> pushmark s ->4
> 4<$> const(PV "CGI") sM/BARE ->5
> 5<$> method_named(PV "new") ->6
> -e syntax OK
>
> ~% perl -MO=Concise -e'"CGI"->new'
> 7<@> leave[1 ref] vKP/REFC ->(end)
> 1<0> enter ->2
> 2<;> nextstate(main 1 -e:1) v:{ ->3
> 6<1> entersub[t1] vKS/TARG ->7
> 3<0> pushmark s ->4
> 4<$> const(PV "CGI") sM ->5
> 5<$> method_named(PV "new") ->6
> -e syntax OK
>
> I don't know whether that extra '/BARE' makes any difference, though.
% perl -MO=Concise -e'CGI::->new'
7 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v:{ ->3
6 <1> entersub[t1] vKS/TARG ->7
3 <0> pushmark s ->4
4 <$> const[PV "CGI"] sM/BARE ->5
5 <$> method_named[PV "new"] ->6
-e syntax OK
maybe somebody who mangles the guts of perl can enlighten us?
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe."
------------------------------
Date: Tue, 30 Mar 2010 20:38:26 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: equivalent
Message-Id: <hou5i8$i85$2@speranza.aioe.org>
On 3/30/2010 8:33 PM, Tad McClellan wrote:
> Ben Morrow<ben@morrow.me.uk> wrote:
>> Quoth Justin C<justin.1003@purestblue.com>:
>
>>> $q = new CGI;
>
>> Method calls like
>>
>> new Class;
>> method $object;
>> method $object @args; # note the lack of comma after $object
>>
>> are in a form usually called 'indirect object syntax'[0]. This was added
>> into Perl when objects were first introduced (5.000, I believe),
>
>
> OP should see the docs section "Indirect Object Syntax" in perlobj.pod.
>
> But it contradicts Ben too:
>
> The other way to invoke a method is by using the so-called "indirect
> object" notation. This syntax was available in Perl 4 long before
> objects were introduced...
out of curiosity, what did it do in perl4?
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe."
------------------------------
Date: Tue, 30 Mar 2010 16:39:40 -0700 (PDT)
From: Ninja Li <nickli2000@gmail.com>
Subject: Re: File formatting
Message-Id: <2f76bb2b-d6e9-4a19-827c-caa1f38d53e3@c13g2000vbb.googlegroups.com>
Thanks for help.
------------------------------
Date: Tue, 30 Mar 2010 11:57:56 -0700
From: sln@netherlands.com
Subject: Re: Text::ParseWords
Message-Id: <i1h4r5p6dolb2s9qp19ni5e0kpcjaakbp1@4ax.com>
On Tue, 30 Mar 2010 09:47:24 -0500, Tad McClellan <tadmc@seesig.invalid> wrote:
>ccc31807 <cartercc@gmail.com> wrote:
>> See the script and output below. The problem is that DATA contains a
>> single quote in the name O'Toole. Is there any way to get this to
>> work? Or do I have to roll my own?
>>
>> Or (horrors) do I have to munge DATA to escape every single quote?
>
>
>Where is the horror in that?
>
>
>> ---------------------script---------------------
>> use strict;
>> use warnings;
>> use Text::ParseWords;
>>
>> while (<DATA>)
>> {
>> chomp;
>> #my ($id, $first, $last, $csz) = split /,/;
>
>
> s/'/\\'/g; # that doesn't seem horrible to me...
> # unless you have single-quoted 'strings' in DATA
^^^^
98765,Sean,O'Toole,"O'Dublin, Ireland"
Thats a big restriction there, hardly a workaround solution.
Its too bad though, with a little extra work,
they could have got it right.
-sln
========================
Output:
c:\temp>perl parse_line.pl
1234, John, Smith, "New York, NY"
2345, Karl, Tomas, "Boston, MA"
98765, Sean, O'Toole, "Dublin, Ireland"
34567, Lewis, Uberville, "Nashville, TN"
c:\temp>
## parse_line.pl
##
use strict;
use warnings;
my $PERL_SINGLE_QUOTE = 0;
use strict;
use warnings;
#use Text::ParseWords;
print "\n";
while (<DATA>)
{
chomp;
my ($id, $first, $last, $csz) = parse_line(',', 1, $_);
print "$id, $first, $last, $csz\n";
}
exit(0);
## -----------------------------------------
## sub parse_line()
## Copyright @ 4/30/2010, by sln
## All rights reserved
## -----------------------------------------
sub parse_line {
my($delimiter, $keep, $line) = @_;
my($word, @pieces);
no warnings 'uninitialized'; # we will be testing undef strings
while (length($line)) {
# This pattern is optimised to be stack conservative on older perls.
# Do not refactor without being careful and testing it on very long strings.
# See Perl bug #42980 for an example of a stack busting input.
$line =~ s/^
(?:
(?:
# double quoted string
(") # $quote
((?>[^\\"]*(?:\\.[^\\"]*)*))" # $quoted
| # --OR--
# singe quoted string
(') # $quote
((?>[^\\']*(?:\\.[^\\']*)*))' # $quoted
| # --OR--
# unquoted string
( # $unquoted
(?:\\.|[^\\"'])*?
)
# followed by
( # $delim
\Z(?!\n) # EOL
| # --OR--
(?-x:$delimiter) # delimiter
| # --OR--
(?!^)(?=["']) # a quote
)
)
| # --OR--
(['"]) # $unquoted quote
)
//xs or return; # extended layout
my ($quote, $quoted, $unquoted, $delim) = (($1 ? ($1,$2) : ($3,$4)), ($5 ? $5 : $7), $6);
return() unless( defined($quote) || length($unquoted) || length($delim));
if ($keep) {
$quoted = "$quote$quoted$quote";
}
else {
$unquoted =~ s/\\(.)/$1/sg;
if (defined $quote) {
$quoted =~ s/\\(.)/$1/sg if ($quote eq '"');
$quoted =~ s/\\([\\'])/$1/g if ( $PERL_SINGLE_QUOTE && $quote eq "'");
}
}
$word .= substr($line, 0, 0); # leave results tainted
$word .= defined $quote ? $quoted : $unquoted;
if (length($delim)) {
push(@pieces, $word);
push(@pieces, $delim) if ($keep eq 'delimiters');
undef $word;
}
if (!length($line)) {
push(@pieces, $word);
}
}
return(@pieces);
}
__DATA__
1234,John,Smith,"New York, NY"
2345,Karl,Tomas,"Boston, MA"
98765,Sean,O'Toole,"Dublin, Ireland"
34567,Lewis,Uberville,"Nashville, TN"
------------------------------
Date: Tue, 30 Mar 2010 19:21:45 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: the mug of Perl
Message-Id: <p2s987-4b21.ln1@osiris.mauzo.dyndns.org>
Quoth John Bokma <john@castleamber.com>:
>
> As for what I would put on a cheat sheet:
> http://johnbokma.com/perl/perl-quick-reference-card.html
Hmm. My reaction to lists like that is 'isn't that just all the stuff
you hold in your head?', but I guess if it isn't a cheat sheet is
useful.
What does 'atomic' mean wrt regex metachars?
Ben
------------------------------
Date: Tue, 30 Mar 2010 13:09:56 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: the mug of Perl
Message-Id: <87wrwt8w3f.fsf@castleamber.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth John Bokma <john@castleamber.com>:
>>
>> As for what I would put on a cheat sheet:
>> http://johnbokma.com/perl/perl-quick-reference-card.html
>
> Hmm. My reaction to lists like that is 'isn't that just all the stuff
> you hold in your head?', but I guess if it isn't a cheat sheet is
> useful.
I certainly don't have all that information on that cheat sheet in my
head. The reason I made it was that some of the more exotic (to me) file
test ops I couldn't recall which one did which, and some other stuff I
had to look up when needed. Originally some notes on an index card, then
I decided to type it in and print it out. And while typing it in, I
decided to make it useful to more people.
To be honest, after I made it and printed out my own version I've used
it rarely. Can't even recall where my print out is at the moment
:-). One advantage of typing stuff in like this is that you learn a lot
(well, I did). I got better at Textpad after I made a similar cheat
sheet: http://johnbokma.com/textpad/quick-reference-card.html
> What does 'atomic' mean wrt regex metachars?
"To avoid confusing, we'll call the thing with width an atom" p141,
Programming Perl.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Tue, 30 Mar 2010 12:11:42 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: the mug of Perl
Message-Id: <r9i4r590k2kvi2kmbhn7l674cf8lvfiufh@4ax.com>
John Bokma <john@castleamber.com> wrote:
>As for what I would put on a cheat sheet:
>http://johnbokma.com/perl/perl-quick-reference-card.html
>
>Note that it's outdated, and probably incomplete. I hope to have time
>soon to add the more recent stuff to it, and also add what is available
>since which version of Perl.
I find it very interesting where you put the emphasis on your sheet:
3 1/2 columns out of 5 deal with regular expressions, only 1 1/2 are
actually Perl itself..
What I would include/add from my perspective:
- Perl functions by name sorted by category as in perldoc perlfunc but
with argument list and return value, including indication for optional
arguments
- Perl syntax, at least for less common constructs, e.g. modifiers
- syntax (maybe by examples) for references and OO
jue
------------------------------
Date: Tue, 30 Mar 2010 13:34:01 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: the mug of Perl
Message-Id: <87oci58uza.fsf@castleamber.com>
Jürgen Exner <jurgenex@hotmail.com> writes:
> John Bokma <john@castleamber.com> wrote:
>>As for what I would put on a cheat sheet:
>>http://johnbokma.com/perl/perl-quick-reference-card.html
>>
>>Note that it's outdated, and probably incomplete. I hope to have time
>>soon to add the more recent stuff to it, and also add what is available
>>since which version of Perl.
>
> I find it very interesting where you put the emphasis on your sheet:
> 3 1/2 columns out of 5 deal with regular expressions, only 1 1/2 are
> actually Perl itself..
:-). Note that there is more than one columm blank, and I am open to
suggestions what to put there.
> What I would include/add from my perspective:
> - Perl functions by name sorted by category as in perldoc perlfunc but
> with argument list and return value, including indication for optional
> arguments
Yes, I have been thinking about that. Or at least the Perl functions
that set as a side effect $! or similar [1]. But (!) a function can be
looked up using perldoc -f function. OTOH, Programming Perl's function
reference is sometimes more clear regarding if $! is set or not. For
example, perldoc -f chdir doesn't mention [2] that $! is set if false is
returned, while PP's entry for chdir makes this clear with a boxed $! to
the right of chdir and it has an example that shows this.
On top of that the PP documentation also shows that chdir raises and
exception if fed tainted data.
> - Perl syntax, at least for less common constructs, e.g. modifiers
> - syntax (maybe by examples) for references and OO
There are several Perl cheat sheets out there that cover this
information. references and OO in itself would be 2+ pages I am
afraid. Especially if you want to include modern Perl stuff (Moose,
etc.).
[1] Like Programming Perl does with the small boxes to the right of the
function name in the "Perl functions in alphabetical order" section.
[2] explicitely I mean, it can be guessed from the context, though.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Tue, 30 Mar 2010 21:31:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: the mug of Perl
Message-Id: <9l3a87-v931.ln1@osiris.mauzo.dyndns.org>
Quoth John Bokma <john@castleamber.com>:
> Jürgen Exner <jurgenex@hotmail.com> writes:
>
> > What I would include/add from my perspective:
> > - Perl functions by name sorted by category as in perldoc perlfunc but
> > with argument list and return value, including indication for optional
> > arguments
>
> Yes, I have been thinking about that. Or at least the Perl functions
> that set as a side effect $! or similar [1]. But (!) a function can be
> looked up using perldoc -f function. OTOH, Programming Perl's function
> reference is sometimes more clear regarding if $! is set or not. For
> example, perldoc -f chdir doesn't mention [2] that $! is set if false is
> returned, while PP's entry for chdir makes this clear with a boxed $! to
> the right of chdir and it has an example that shows this.
>
> On top of that the PP documentation also shows that chdir raises and
> exception if fed tainted data.
This is the sort of thing that would make a perfect doc patch. Much of
the documentation of basic functions like this dates from the days when
you were expected to know that $! was errno, and check your local
chdir(2) to see what it might be set to, and most of the porters
probably don't read it often enough to notice where it hasn't been
updated.
Doc patches from people who actually read the docs because they don't
know how things work yet are always the most valuable, and not always
easy to come by.
<snip>
> [1] Like Programming Perl does with the small boxes to the right of the
> function name in the "Perl functions in alphabetical order" section.
If you felt like going through perlfunc and adding this sort of
annotation to the entries I expect p5p would accept a patch. (I can't
guarantee anything, of course, seeing as I don't have a commit bit.)
Ben
------------------------------
Date: Tue, 30 Mar 2010 22:31:40 +0100
From: Justin C <justin.1003@purestblue.com>
Subject: Re: the mug of Perl
Message-Id: <s67a87-npc.ln1@purestblue.com>
In article <f63f9acd-ed20-4442-a1f1-6b2cd6503179@8g2000yqz.googlegroups.com>, ccc31807 wrote:
> http://nostarch.com/mugperl.htm
>
> cheat sheet is here:
>
> http://nostarch.com/mugperl_big.htm
>
> The cheat sheet appears to be targeted more to the casual user rather
> than to the daily grind. I wondering what would appear on a cheat
> sheet for journeymen Perlistas. My nomination would include the ||=
> operator.
13 bucks for a mug? What kinda mug do you take me for?!
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 31 Mar 2010 01:37:06 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: the mug of Perl
Message-Id: <4bb28b22$0$22933$e4fe514c@news.xs4all.nl>
John Bokma wrote:
> http://johnbokma.com/perl/perl-quick-reference-card.html
Another:
http://juerd.nl/site.plp/perlcheat
--
Ruud
------------------------------
Date: Wed, 31 Mar 2010 01:24:49 +0200
From: Bo Lindbergh <blgl@hagernas.com>
Subject: Re: unary minus strangeness
Message-Id: <hou17n$c4c$1@speranza.aioe.org>
For real strangeness, you need to mix negative zero, boolean context,
and stringification.
{
my $strange=-0.0;
print $strange ? "$strange is true\n" : "$strange is false\n";
print $strange ? "$strange is true\n" : "$strange is false\n";
}
/Bo Lindbergh
------------------------------
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 2896
***************************************
