From: Ben Morrow on

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

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.