From: Ben Morrow on

Quoth sreservoir <sreservoir(a)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

From: Ben Morrow on

Quoth sreservoir <sreservoir(a)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

From: sreservoir on
On 3/30/2010 7:34 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir(a)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."
From: Tad McClellan on
Ben Morrow <ben(a)morrow.me.uk> wrote:
> Quoth Justin C <justin.1003(a)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.
From: sreservoir on
On 3/30/2010 8:00 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir(a)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."