equivalent
in [Perl]
|
Prev: FAQ 6.15 How can I print out a word-frequency or line-frequency summary?
Next: FAQ 4.63 Why don't my tied hashes make the defined/exists distinction?
From: Ben Morrow on 29 Mar 2010 22:26 Quoth sreservoir <sreservoir(a)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
From: Justin C on 30 Mar 2010 17:10 In article <h44887-vcl.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow wrote: > > Quoth sreservoir <sreservoir(a)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.
From: sreservoir on 30 Mar 2010 18:50 On 3/29/2010 10:19 PM, Ben Morrow wrote: > > Quoth sreservoir<sreservoir(a)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."
From: sreservoir on 30 Mar 2010 19:04 On 3/29/2010 10:26 PM, Ben Morrow wrote: > > Quoth sreservoir<sreservoir(a)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."
From: Ben Morrow on 30 Mar 2010 19:28
Quoth Justin C <justin.1003(a)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. |