[32406] in Perl-Users-Digest
Perl-Users Digest, Issue: 3673 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Apr 23 06:09:20 2012
Date: Mon, 23 Apr 2012 03:09:05 -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 Mon, 23 Apr 2012 Volume: 11 Number: 3673
Today's topics:
Re: Optionally avoid AutoLoader <ben@morrow.me.uk>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Optionally avoid AutoLoader <ben@morrow.me.uk>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Perl on a Mac - again <ben@morrow.me.uk>
Re: Perl on a Mac - again <kst-u@mib.org>
Re: Perl on a Mac <hansmu@xs4all.nl>
Re: Using symbolic references to invoke package methods <rweikusat@mssgmbh.com>
Re: Using symbolic references to invoke package methods (Tim McDaniel)
Re: Using symbolic references to invoke package methods <ben@morrow.me.uk>
Re: Using symbolic references to invoke package methods <ben@morrow.me.uk>
Re: Using symbolic references to invoke package methods (Tim McDaniel)
Re: Using symbolic references to invoke package methods (Tim McDaniel)
Re: Why does this code works without cat ? <rweikusat@mssgmbh.com>
Re: Why does this code works without cat ? <whynot@pozharski.name>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 22 Apr 2012 19:08:46 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <e2ud69-md9.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Apr 22, 12:03 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > Not 'use #line', just a line like
>
> Sorry but then... it is already there: AutoSplit put it!
> I have in describe.al (line 6):
> #line 2871 "blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/lib/
> auto/ClearCase/Wrapper/MGi/describe.al)"
>
> Now, this seems (in this context) to create a problem for the debugger
> (perl -d).
> - I cannot put a breakpoint beyond this point, using either the
> original or the corrected line number
> - The 'v' command refuses to show any code
I don't generally use the debugger, so I'm not entirely sure how it
behaves, but I would expect that it will never be happy with files which
use #line, or with any system which tries to read a source file more
than once.
When in debug mode, perl stuffs all the lines it reads into an array
named after the filename passed to 'require'; later, when you try to set
a breakpoint, the debugger looks up the file and line stored against the
relevant statement and tries to match it up against one of those arrays.
#line only changes the filename and line which get stored against each
statement, not which magic array the source lines get stuffed into, so
the debugger can't match them up any more.
I don't think there's any way around this, short of dropping AutoLoader
altogether. Can you not just comment out the __END__ line during
development, which will cause all the subs to be loaded promptly and
bypass AUTOLOAD altogether?
> > No it didn't. AutoSplit treats the code to be split purely as text, it
> > doesn't compile it.
>
> OK. Only, in the normal development lifecycle, which I'd wish to
> disturb as little as possible for backwards compatibility reasons,
> autosplit is invoked as part of the 'make'
Yes... the 'make' step doesn't compile your Perl code either, it just
moves it around. Perl is a just-in-time compiler, so nothing is compiled
until after a program using the module actually starts running.
> Will the splitting take place if the build fails?
> As it would because of a strict/warnings report...
You don't get strict or warnings errors at 'make' time anyway, because
your code isn't run (so it isn't compiled). 'make test' will (probably)
run most of it, but that's an entirely separate step which nothing else
depends on: the rest of the build will carry on just fine if it fails,
or if you don't run it at all.
> I cannot understand why/how these messages are lost (in my
> experience...).
> Looking at the AutoLoader::AUTOLOAD code, it seems to croak such
> messages:
>
> if ($@){
> $@ =~ s/ at .*\n//;
> my $error = $@;
> require Carp;
> Carp::croak($error);
> }
This happens when AutoLoader::AUTOLOAD is called, which isn't until a
process which is using your module has tried to call an autoloaded sub.
Again, 'make test' might (ought to) invoke all the autoloaded subs at
least once, but other than that this doesn't happen until long after
you've run 'make install'.
Ben
------------------------------
Date: Sun, 22 Apr 2012 11:30:25 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <40017d3c-2705-4b84-b8e5-b38396001b43@h20g2000yqd.googlegroups.com>
On Apr 22, 5:13=A0pm, Marc Girod <marc.gi...@gmail.com> wrote:
> Now, this seems (in this context) to create a problem for the debugger
> (perl -d).
If I do, at the debugger prompt, and after the point where I have
loaded all the .al files:
DB<8> f MGi.pm
Choosing blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/lib/
auto/ClearCase/Wrapper/MGi/_Checkcs.al) matching `MGi.pm':
1 2 3 4 5 6 7 8 9 10
I don't quite understand this output.
However, what actually got loaded is the first .al file (in the
alphabetic order): _Checkcs.al, and there:
DB<12> v 191
188 189 190 191 sub _Checkcs {
192: use File::Basename;
193: use Cwd;
194: my ($v) =3D @_;
195: $v =3D~ s/^(.*?)\@\@.*$/$1/;
196: my $dest =3D dirname($v);
197: $dest .=3D '/' unless $dest =3D~ m%/$%;
This 191 comes from the cpp #line directive in the file:
#line 191 "blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/lib/
auto/ClearCase/Wrapper/MGi/_Checkcs.al)"
The first output showed line numbers, which until line 191, are
'empty'...?
Is it possible to load the other fragments?
Marc
------------------------------
Date: Sun, 22 Apr 2012 23:55:34 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <6see69-7vb.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Apr 22, 5:13 pm, Marc Girod <marc.gi...@gmail.com> wrote:
>
> > Now, this seems (in this context) to create a problem for the debugger
> > (perl -d).
>
> If I do, at the debugger prompt, and after the point where I have
> loaded all the .al files:
>
> DB<8> f MGi.pm
> Choosing blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/lib/
> auto/ClearCase/Wrapper/MGi/_Checkcs.al) matching `MGi.pm':
> 1 2 3 4 5 6 7 8 9 10
>
> I don't quite understand this output.
I don't use the debugger. IME it has too much of a tendency to produce
surprising and unhelpful results. (I don't use AutoLoader either, for
the same reason.)
It looks to me as though the debugger has found the first file which
matches /MGi.pm/, going by #line directives. That suggests you could
examine the other .al files by asking for them by name. I didn't know
the debugger saw the effects of #line at all, but it seems that it does.
That ought to mean it can set breakpoints within sub _Checkcs: if that
doesn't work then I don't know why. (Obviously you won't be able to set
breakpoints until after the .al has been loaded.)
> However, what actually got loaded is the first .al file (in the
> alphabetic order): _Checkcs.al, and there:
>
> DB<12> v 191
> 188 189 190 191 sub _Checkcs {
> 192: use File::Basename;
> 193: use Cwd;
> 194: my ($v) = @_;
> 195: $v =~ s/^(.*?)\@\@.*$/$1/;
> 196: my $dest = dirname($v);
> 197: $dest .= '/' unless $dest =~ m%/$%;
>
> This 191 comes from the cpp #line directive in the file:
>
> #line 191 "blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/lib/
> auto/ClearCase/Wrapper/MGi/_Checkcs.al)"
>
> The first output showed line numbers, which until line 191, are
> 'empty'...?
Well, if the first physical line in the file is supposed to be logical
line 191, you would expect the lines before that to be empty.
> Is it possible to load the other fragments?
What happened when you tried it?
Ben
------------------------------
Date: Mon, 23 Apr 2012 00:39:59 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <fa6dd567-3525-4fef-bb70-a5cb780d7efc@w5g2000vbp.googlegroups.com>
On Apr 22, 11:55=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> I don't use the debugger.
Well, I do. In fact, the debugger plays an important role in my using
Perl.
Anyway, I have to support users of the modules.
> What happened when you tried it?
I can load the .al files by name, but then, I cannot even read the
code (hence not put breakpoints).
I couldn't find a syntax to load any other file but the first
(_Checkcs.al), which I load as 'MGi.pm'.
Marc
------------------------------
Date: Sun, 22 Apr 2012 19:47:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl on a Mac - again
Message-Id: <kb0e69-6v9.ln1@anubis.morrow.me.uk>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Sun, 22 Apr 2012 17:27:38 +0000, Tim McDaniel wrote:
>
> > A bad practice that I've seen decryed. If you have a script that
> > depends on some feature of the original Bourne shell, or strict POSIX
> > compatibility, it's really nasty to have /bin/sh be something else.
Relatively few systems use a true Bourne shell any more, since it isn't
freely available. About the closest is ash, which has test(1) built in.
> All serious bourne like shells emulate a POSIX sh if called as sh.
Not to the extent of not providing test as a builtin:
~% /bin/sh -c 'PATH=/var/empty test -x /bin/sh && echo yes'
yes
~%
This is with ash as /bin/sh. Bash is much worse:
~% /bin/sh -c '[[ -x /bin/sh ]] && echo yes'
[[: not found
~% ln -s /usr/local/bin/bash sh
~% ./sh -c '[[ -x /bin/sh ]] && echo yes'
yes
~%
not to mention
~% ./sh --version
GNU Bash, ...
...
which is just sick and wrong (though not quite as bad as GNU true(1)).
> > Better, and I think (or at least hope more common) is to simply provide
> > a different login shell. For example, on my ISP,
> >
> > tmcd:*:<uid>:<gid>:Tim McDaniel:<home directory>:/usr/local/bin/bash
>
> Bash called as bash, all bash goodies available. On most systems I know /
> bin/sh is either a symlink or a hardlink to ksh or bash. If you feel that
> is a problem, you have a lot of vendors to convince.
Debian and all (I think) of the BSDs use ash as /bin/sh, which was
explicitly written to be a POSIX /bin/sh with minimal extensions.
Solaris appears to use a derivatve of the original Bourne shell, with
job control but without kshish POSIX features like $().
Ben
------------------------------
Date: Sun, 22 Apr 2012 14:05:29 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Perl on a Mac - again
Message-Id: <lnfwbvpjdy.fsf@nuthaus.mib.org>
tmcd@panix.com (Tim McDaniel) writes:
[...]
> All this is a lot of detail. Short form:
> - don't name a test program "test"
> - invoke your own test programs with a path like ./foo or ~/foo
> or /home/login/foo
Good advice, but ...
*If* you carefully keep "." out of your $PATH *and* develop the
habit of invoking commands in the current directory as "./whatever",
then naming your own test program "test" isn't a problem.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Sun, 22 Apr 2012 20:58:52 +0200
From: Hans Mulder <hansmu@xs4all.nl>
Subject: Re: Perl on a Mac
Message-Id: <4f9454ed$0$6868$e4fe514c@news2.news.xs4all.nl>
On 22/04/12 19:27:38, Uri Guttman wrote:
>>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
>
> BM> Perl always parses arguments from the #! line, on all OSs. Even on OSs
> BM> which understand #!, the kernel always passes the whole of the rest of
> BM> that line (up to a fixed limit) as one argument, and on some OSs that
> BM> limit was rather small. Perl goes to some trouble to sort out the
> BM> resulting mess so you can apparently put several arguments on the #!
> BM> line and it will Just Work.
> perl gets the #! just by reading the source file it is passed. it
> doesn't need any help from the kernel to see it all.
One exception to this, is the '-T' switch. If you let the kernel process
the shebang line, then it will pass the -T on the command line and perl
will run in taint mode. It perl only finds the -T when it parses the
first line of the source file, then it's too late and perl will abort:
$ cat demo.pl
#!/usr/bin/perl -T
print "Hello, world\n";
$ ./demo.pl
Hello, world
$ perl demo.pl
"-T" is on the #! line, it must also be used on the command line at
demo.pl line 1.
$ perl -T demo.pl
Hello, world
$
-- HansM
------------------------------
Date: Sun, 22 Apr 2012 19:56:04 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <878vhny4sb.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth tmcd@panix.com:
[...]
>> But calling the literal strings 'blubb' and 'blah' work fine, and they
>> follow inheritance.
>
> Are you looking for ->can? This resolves the method and returns a
> coderef: it's effectively the equivalent of \&foo for methods. (And,
> just like \&foo, it will under some circumstances return a stub, which
> may or may not turn out to resolve to a real method when you call
> it.)
As addition to the already posted code (tested on 5.10.1):
-------------
# nor this
#'
eval {
$c->can($_)->() for qw(blubb blah);
};
print("$@");
# nor this
#'
eval {
$c->$_() for map { Child->can($_); } qw(blubb blah);
};
print("$@");
-------------
NB: At least with Perl 5.10.1, using map in this way together with for
is not a good idea: At the implementation level, this is a two pass
algorithm which first iterates over all of the 'input' values in order
to create the list returned by map and then loops over this list,
executing the actual loop body.
------------------------------
Date: Sun, 22 Apr 2012 20:04:14 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <jn1o7u$dpp$1@reader1.panix.com>
In article <878vhny4sb.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>Ben Morrow <ben@morrow.me.uk> writes:
>> Quoth tmcd@panix.com:
>
>[...]
>
>
>>> But calling the literal strings 'blubb' and 'blah' work fine, and they
>>> follow inheritance.
>>
>> Are you looking for ->can? This resolves the method and returns a
>> coderef: it's effectively the equivalent of \&foo for methods. (And,
>> just like \&foo, it will under some circumstances return a stub, which
>> may or may not turn out to resolve to a real method when you call
>> it.)
>
>As addition to the already posted code (tested on 5.10.1):
>
>-------------
># nor this
>#'
>eval {
> $c->can($_)->() for qw(blubb blah);
>};
>print("$@");
>
># nor this
>#'
>eval {
> $c->$_() for map { Child->can($_); } qw(blubb blah);
>};
>print("$@");
To expand on that:
The example had package Parent with sub blah, package Child ISA Parent
and adding sub blubb, "my $c = Child->new();". Both of the two evals
above result in the error messages
Undefined subroutine &Child::blah called at ...
Which I don't understand, given that "man UNIVERSAL" on my current
system says
"$obj->can( METHOD )"
"CLASS->can( METHOD )"
"eval { VAL->can( METHOD ) }"
"can" checks if the object or class has a method called
"METHOD". If it does, then it returns a reference to the sub.
If it does not, then it returns undef. This includes methods
inherited or imported by $obj, "CLASS", or "VAL".
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 22 Apr 2012 21:20:45 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <tp5e69-pea.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > Are you looking for ->can? This resolves the method and returns a
> > coderef: it's effectively the equivalent of \&foo for methods. (And,
> > just like \&foo, it will under some circumstances return a stub, which
> > may or may not turn out to resolve to a real method when you call
> > it.)
>
> As addition to the already posted code (tested on 5.10.1):
>
> -------------
> # nor this
> #'
> eval {
> $c->can($_)->() for qw(blubb blah);
> };
> print("$@");
This isn't supposed to work: the coderef returned by can does not
include an implicit invocant, you have to provide one explicitly.
> # nor this
> #'
> eval {
> $c->$_() for map { Child->can($_); } qw(blubb blah);
> };
> print("$@");
This works just fine, though I would prefer to write $c->can rather than
Child->can. There are classes which overload ->can in such a way that
different objects can return different values; an example would be
Test::MockObject.
> NB: At least with Perl 5.10.1, using map in this way together with for
> is not a good idea: At the implementation level, this is a two pass
> algorithm which first iterates over all of the 'input' values in order
> to create the list returned by map and then loops over this list,
> executing the actual loop body.
It is in principle a little less efficient than a streaming
implementation, yes, though for a list of two elements (or, indeed, 200)
this is extremely unlikely to be visible in practice. Trying to avoid
temporary lists means effectively avoiding 'for' altogether, and it's
far too useful for that.
(I do wish Perl 5 had lazy lists. They would be extremely useful,
sometimes, and are so much clearer than an explicit while loop.)
Ben
------------------------------
Date: Sun, 22 Apr 2012 21:28:01 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <h76e69-pea.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <878vhny4sb.fsf@sapphire.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> >
> >As addition to the already posted code (tested on 5.10.1):
> >
> >-------------
> ># nor this
> >#'
> >eval {
> > $c->can($_)->() for qw(blubb blah);
> >};
> >print("$@");
> >
> ># nor this
> >#'
> >eval {
> > $c->$_() for map { Child->can($_); } qw(blubb blah);
> >};
> >print("$@");
>
> To expand on that:
>
> The example had package Parent with sub blah, package Child ISA Parent
> and adding sub blubb, "my $c = Child->new();". Both of the two evals
> above result in the error messages
>
> Undefined subroutine &Child::blah called at ...
What code are you running, exactly? If I run
#!/usr/bin/perl
{
package Parent;
sub new { bless [], $_[0] }
sub blah { warn "blah" }
}
{
package Child;
our @ISA = "Parent";
sub blubb { warn "blubb" }
}
my $c = Child->new;
eval {
$c->$_() for map { Child->can($_); } qw(blubb blah);
};
warn "err: $@";
I get
blubb at can line 12.
blah at can line 6.
err: at can line 20.
Just to be sure something weird wasn't going on, I even checked with
5.10.1.
(And, in fact, Rainer's first version above works just fine, too, since
the subs don't look at $_[0]. In general this won't be the case.)
Ben
------------------------------
Date: Mon, 23 Apr 2012 05:59:01 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <jn2r35$737$1@reader1.panix.com>
In article <h76e69-pea.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> In article <878vhny4sb.fsf@sapphire.mobileactivedefense.com>,
>> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> >
>> >As addition to the already posted code (tested on 5.10.1):
>> >
>> >-------------
>> ># nor this
>> >#'
>> >eval {
>> > $c->can($_)->() for qw(blubb blah);
>> >};
>> >print("$@");
>> >
>> ># nor this
>> >#'
>> >eval {
>> > $c->$_() for map { Child->can($_); } qw(blubb blah);
>> >};
>> >print("$@");
>>
>> To expand on that:
>>
>> The example had package Parent with sub blah, package Child ISA Parent
>> and adding sub blubb, "my $c = Child->new();". Both of the two evals
>> above result in the error messages
>>
>> Undefined subroutine &Child::blah called at ...
>
>What code are you running, exactly? If I run
>
> #!/usr/bin/perl
>
> {
> package Parent;
> sub new { bless [], $_[0] }
> sub blah { warn "blah" }
> }
>
> {
> package Child;
> our @ISA = "Parent";
> sub blubb { warn "blubb" }
> }
>
> my $c = Child->new;
>
> eval {
> $c->$_() for map { Child->can($_); } qw(blubb blah);
> };
> warn "err: $@";
>
>I get
>
> blubb at can line 12.
> blah at can line 6.
> err: at can line 20.
>
>Just to be sure something weird wasn't going on, I even checked with
>5.10.1.
5.10.1 here, and the test program in 102.pl is as follows: it's the
example from a few articles back with Rainer's. I know so
little about packages and classes and such in Perl that I can't start
to see what might be significant about differences. You wrap the
backages in blocks and the original does not.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
package Parent;
sub new {
return bless([], $_[0]);
}
sub blah
{
print("Blah!\n");
}
package Child;
our @ISA = qw(Parent);
sub blubb
{
print("Blubb!\n");
}
package main;
my $c = Child->new();
# call the method
#
$c->$_() for (qw(blubb blah));
# this doesn't work
#
eval {
$c->$_() for (\&blubb, \&blah);
};
print("$@");
# neither does this
#
eval {
$c->$_() for (\&Child::blubb, \&Child::blah);
};
print("$@");
# nor this
#'
eval {
$c->can($_)->() for qw(blubb blah);
};
print("$@");
# nor this
#'
eval {
$c->$_() for map { Child->can($_); } qw(blubb blah);
};
print("$@");
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The output:
$ perl local/test/102.pl
Blubb!
Blah!
Undefined subroutine &main::blubb called at local/test/102.pl line 32.
Blubb!
Undefined subroutine &Child::blah called at local/test/102.pl line 39.
Blubb!
Undefined subroutine &Child::blah called at local/test/102.pl line 46.
Blubb!
Undefined subroutine &Child::blah called at local/test/102.pl line 53.
------------------------------
Date: Mon, 23 Apr 2012 06:04:53 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <jn2re5$737$2@reader1.panix.com>
In article <tp5e69-pea.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > Are you looking for ->can? This resolves the method and returns a
>> > coderef: it's effectively the equivalent of \&foo for
>> > methods. (And, just like \&foo, it will under some circumstances
>> > return a stub, which may or may not turn out to resolve to a real
>> > method when you call it.)
>>
>> As addition to the already posted code (tested on 5.10.1):
>>
>> -------------
>> # nor this
>> #'
>> eval {
>> $c->can($_)->() for qw(blubb blah);
>> };
>> print("$@");
>
>This isn't supposed to work: the coderef returned by can does not
>include an implicit invocant, you have to provide one explicitly.
>
>> # nor this
>> #'
>> eval {
>> $c->$_() for map { Child->can($_); } qw(blubb blah);
>> };
>> print("$@");
>
>This works just fine
It took me a bit of looking at the second to decode the first
comment. Is this what it means?
$c->can('blubb') or whatever returns a reference to a sub --
specifically a reference to a class method. To use any class method,
you need to apply it to something, like an instance of the class. So
$c->($c->can('blubb'))->() should work (and I think you need not put
in the last "->").
Given that the subs in the example code I was working from (just
posted in anothe rfork of this thread) do not refer to @_, do these
particular subs really need to be invoked for an object?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 22 Apr 2012 19:57:44 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does this code works without cat ?
Message-Id: <874nsby4pj.fsf@sapphire.mobileactivedefense.com>
xhoster@gmail.com writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
[...]
>> cat in front of any of these command is as useless as in front of
>> perl: They can either all work with files directly or use files the
>> shell opened for them
>
> The point you so cleverly miss is that turning a cat into a grep is let
> easier, and less error-prone, than migrating a redirected file name from
> after the perl -e 'whatever' to before it, and adding a grep.
I'm not missing anything: You don't have a leg to stand on, you're
just a guy who advocates bad coding habits just because they are bad
coding habits.
------------------------------
Date: Mon, 23 Apr 2012 10:36:35 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Why does this code works without cat ?
Message-Id: <slrnjpa1k3.vpn.whynot@orphan.zombinet>
with <slrnjp853f.6h8.hjp-usenet2@hrunkner.hjp.at> Peter J. Holzer wrote:
> On 2012-04-21 09:59, Eric Pozharski <whynot@pozharski.name> wrote:
*SKIP*
>> And who's confused now?
>
> Ok, you just proved me wrong: You *are* confused.
>
> I admit that this particular zsh feature (it doesn't work in bash) is a
> bit confusing:
>
*SKIP* [[ *relevant* description of differences of various shells ]]
And zsh wins!
{6617:23} [0:0]% bash
{1:1} [0:0]$ perl -wle 'print -s STDIN' </etc/passwd </etc/group
1006
{26:2} [0:0]$ perl -nle '$aa++; END { print $aa }' </etc/passwd </etc/group
68
{56:3} [0:0]$ exit
{6889:29} [0:0]% perl -nle '$aa++; END { print $aa }' </etc/passwd </etc/group
105
{6900:30} [0:0]% wc /etc/passwd /etc/group
37 53 1814 /etc/passwd
68 68 1006 /etc/group
105 121 2820 total
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
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 3673
***************************************
