[29043] in Perl-Users-Digest
Perl-Users Digest, Issue: 287 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 31 14:09:55 2007
Date: Sat, 31 Mar 2007 11:09:06 -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 Sat, 31 Mar 2007 Volume: 11 Number: 287
Today's topics:
Re: Comprehensive Reference Books On Perl or CGI. <bik.mido@tiscalinet.it>
Re: Event Handling? <zentara@highstream.net>
Re: handler functions marked as method <bik.mido@tiscalinet.it>
Re: How best to "fix" a bug in a standard module? <socyl@987jk.com.invalid>
Re: HowTo parse huge Files <bik.mido@tiscalinet.it>
Re: import conundrum <thepoet_nospam@arcor.de>
Re: multiple inheritance and instance data? <bik.mido@tiscalinet.it>
Re: multiple inheritance and instance data? <bik.mido@tiscalinet.it>
Re: perl + script files from only one directory <bik.mido@tiscalinet.it>
Re: perl continuation character <bik.mido@tiscalinet.it>
Re: perl continuation character <jurgenex@hotmail.com>
Re: perl continuation character <bik.mido@tiscalinet.it>
Re: perl continuation character <someone@example.com>
Re: Perl package install dll problems <christopher.m.collins@gmail.com>
Re: prototypes - use or not? <please@nospam.net>
Re: Shifting Away <please@nospam.net>
Re: Shifting Away <uri@stemsystems.com>
Re: Shifting Away anno4000@radom.zrz.tu-berlin.de
Re: What are OOP's Jargons and Complexities <bik.mido@tiscalinet.it>
Re: What are OOP's Jargons and Complexities <bik.mido@tiscalinet.it>
Re: What are OOP's Jargons and Complexities <lew@nospam.lewscanon.com>
Re: What are OOP's Jargons and Complexities <lew@nospam.lewscanon.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 31 Mar 2007 14:56:45 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Comprehensive Reference Books On Perl or CGI.
Message-Id: <9bls03le6rv08622pqef3h62ns2pbitln0@4ax.com>
On 30 Mar 2007 09:05:41 -0700, virtualadepts@gmail.com wrote:
>> > I'm busy ordering books on CGI & Perl, but It is hard to find the good
>> > books. I'm looking for something comprehensive and written at a level
>> > for experts using the language to use the books as a reference. Can
^^^^^^^^^^^
^^^^^^^^^^^
>> > anyone link me up to some?
>>
>> Do you mean beyond 'perldoc -q book'?
>>
>> jue
>
>I'm learning Pearl now. It is the hottest damn language out there,
^^^^^^^^^^^^
^^^^^^^^^^^^
Am I the only one to see a contradiction! (Granted, even experienced
Perl hackers are still learning. Something suggests me that's not your
case, thoug.)
>for some clearly good reasons. The language was released for free in
Yes, I think it is probably pointless to come here and boast about how
cool Perl is: we all know. We all are Perl enthusiasts and addicts.
>1988 on Usenet to begin with, so you know it is good already. And
I bet quite a ton of stuff was released for free in 1988 on usenet,
though I doubt that would constitute a sufficient condition for being
good.
>people have been developing source with it within the unix community
>since then. The other good thing about the language, and unix in
And not only. Actually, Perl is widely ported and a very nice feature
of its own is that one can also write fairly portable programs with
it.
OTOH for Windows specific tasks people have developed quite a lot of,
well, Windows specific modules, and while I personally try to stay
portable, I've seen them doing quite impressive stuff.
>general, is there are so many manuals written for it that explain
>everything so clearly that you may as well have a teacher in the room
That's true!
>with you. Perl is the main language people use to code CGI programs,
And quite a lot of other stuff. Please, let's try to break this Perl
eq CGI thing eventually!
>although you could use C, but C doesn't have as much power. CGI is a
You could use more or less *any* programming language.
Both Perl and C, and most other common programming languages are
Turing complete and can do the same exact things, if you don't take
time issues into account: if you do, then C is more efficient
execution time wise, and Perl programmer's time wise. Also, you can
embed C in Perl and vice versa.
>way to run executables as web sites, and that has created the new
Most people here (not necessarily including me) know what CGI is
better than you. No need to explain that. It is not adding any value
to the group. Indeed, it's raising the noise/signal ratio here.
>dot.com revolution now that we have hardware and bandwith that can
>process everything like google, youtube, and myspace. People are
myspace? Now that you remind me, oh what a wonderful world we're
living in!!
But seriously, disregarding the fact that I have a gut feeling against
flash technologies, are you aware that they're vital to youtube?
>writing simple php, html, css scripts. They are coding backends in
html *scripts*? css *scripts*?
>Perl and C++. Sometimes even coding their own webservers. And if you
>get an iMac you are running unix to begin with, and it is easy to see
>that unix programming CGI, & Perl are the future of computers. They
I hope not so. Well, but for the Perl part of course!
>already are here. If you want a career in computers 5 years from now
>you will have to forget all about windows GUI programming and C#.
Never learnt them! Happily so!! But I doubt one who is familiar with
them will go out of job$ in 5 years.
>Knowing how to configure Apache to run php scripts on a windows box
>won't be good enough either. You will have to learn UNIX!!!! UNIX!!!
So Linux, the various breeds of BSD and the tenths of other unices out
there won't do, eh?!?
>And all the manuals are out there by a great publisher Oreilly:
>http://www.oreilly.com/
s/all/many/;
>This company published all of the really good perl, and cgi books, as
>well as some great manuals for unix. The phrase RTFM is my best
s/all/many/;
>friend now that I have an iMac. Because the manuals are just so damn
Nice to know you won't take offense when told to!
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 09:31:38 -0400
From: zentara <zentara@highstream.net>
Subject: Re: Event Handling?
Message-Id: <ikos031dhbtfqq5vc30e9ccegu4jsorgfg@4ax.com>
On 26 Mar 2007 11:36:30 -0700, "zm5" <ryanarossi@gmail.com> wrote:
>Could someone give me a link to a tutorial on event handling in perl?
>I have not been able to find anything, it seems what I always find
>when searching for event handling in perl is signal handling. Are
>these two things one in the same?
>
>Thanks for your help
If you are looking for gui type programs, Tk, Gtk2, etc.
If you are looking for console mode, try Glib or POE.
I like GLib, it's the base lib of the Gtk2 system, but Glib
itself dosn't need X.
See:
http://perlmonks.org?node_id=538341
zentara
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
------------------------------
Date: Sat, 31 Mar 2007 14:08:25 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: handler functions marked as method
Message-Id: <8ojs03llrshcbsvd9t2381qulh7irms9vd@4ax.com>
On Thu, 29 Mar 2007 16:01:58 +0200, "Ferry Bolhar"
<bol@adv.magwien.gv.at> wrote:
>sub handler : method {...}
>
>What does this actually mean? I doubt 'method' was used
>in the threading model of Perl 5.005 only and is now obsolete.
>But mod_perl 2.0 requires at least Perl 5.6, so the above
>declaration would make no sense. So I'd guess there's
>another reason for it.
>
>So why and when one should declare a function as 'method'?
From perldoc attributes:
: method
: Indicates that the referenced subroutine is a method. This has a
: meaning when taken together with the locked attribute, as described
: there. It also means that a subroutine so marked will not trigger
: the "Ambiguous call resolved as CORE::%s" warning.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 11:20:34 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: How best to "fix" a bug in a standard module?
Message-Id: <eulg62$h4d$1@reader2.panix.com>
In <574o9eF2bql82U1@mid.dfncis.de> anno4000@radom.zrz.tu-berlin.de writes:
>kj <socyl@987jk.com.invalid> wrote in comp.lang.perl.misc:
>>
>>
>>
>> I frequently run into minor bugs in modules downloaded from CPAN.
>> Aside from the issue of reporting the bug to the modules' maintainers,
>> there's still the immediate problem of fixing the bug for our own
>> use.
>>
>> AFAIC, it is out of the question to replace the installed module
>> with one I have fixed.
>Why?
Primarily because among my cow-orkers there are a few whose notions
of what constitute bugs, and whose ability to "fix" them, I don't
trust for a second. If I were to fix a standard module "in place",
as it were, I'd be setting a precedent that'd effectively give
these clowns permission to do the same thing. This is a scary
prospect.
Besides, some other code in our codebase may already expect and
work with the buggy behavior, so the ad-hoc "in place" fixes could
conceivably break this code. Of course, this will happen when the
buggy module gets fixed in a later version, but it looks to me that
letting these fixes correspond to "official" releases of the module
will ultimately result in less cumulative confusion.
kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Sat, 31 Mar 2007 13:44:41 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: HowTo parse huge Files
Message-Id: <o5is03dovf0ujn48i18vv3v1s0vr4ofqdp@4ax.com>
On Thu, 29 Mar 2007 09:50:37 -0500, Uri Guttman <uri@stemsystems.com>
wrote:
> cc> if (<$fh> =~ m/$item/) {
>
>that is very wrong. it reads a new line in for each match in the
Unless he really wanted to do so. Of course, all odds are against this
remote possibility. :-)
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 16:47:21 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: import conundrum
Message-Id: <460e746f$0$23145$9b4e6d93@newsspool1.arcor-online.net>
kj wrote:
> According to the documentation for "use", if one wants to prevent
> a module's import from being called when the module is use'd, one
> is supposed pass an empty list as the second argument to "use":
>
> use Foo::Bar ();
>
> But now suppose that Foo::Bar in turn use's some other module Foo:
[...snipped..]
>
> Is there any other for Foo to know that it has been use'd by a
> module that *itself* was use'd with a "()" argument?
I don't think that there's a direct approach. But you can have
a look at http://www.a-za-z0-9.de/perl/noimport.pm
I've toyed around with import hooks some time ago and changed
the code now a bit to enable you to say something like
use noimport qw(Foo Foo::Bar);
to suppress calling their import, or even leting you specify
alternate code with
use noimport (
"Foo",
["Foo::Bar" => 'print "I am imported$/";']
);
Though it's quite a kludge, as it only looks for the entry
"sub import" at the beginning of a line and replaces it with
an empty (or user supplied) import function while copying it
to a temporary directory, something that doesn't work for
autogenerated subs. But you might get new ideas from it.
-Chris
------------------------------
Date: Sat, 31 Mar 2007 14:01:18 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: multiple inheritance and instance data?
Message-Id: <88js03t2qnd14s1df03su5tb28o5n5g0a9@4ax.com>
On Fri, 30 Mar 2007 08:55:07 +0100, bugbear
<bugbear@trim_papermule.co.uk_trim> wrote:
>In particular, \do, Scalar::Util 'refaddr', \my,
>and the (I assume careful...) use of blocks
>is all new to me.
C<\> takes a reference, and that's all. do() and my() are still old
plain do() and my(). The blocks serve the purpose of creating lexical
scopes, as is often the case, no more no less.
>Rather than ask you a load of questions about
>your design, do you have a reference or tutorial
>you could point me too?
Neither a reference nor a tutorial, but may be a good intro for you -
David Golden's YAPC::NA talk:
http://dagolden.com/files/Eversion_101.pdf
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 16:49:00 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: multiple inheritance and instance data?
Message-Id: <k6ts03hm7kc92uatcm2mbs6md0hs1oin2j@4ax.com>
On Fri, 30 Mar 2007 09:23:20 +0100, bugbear
<bugbear@trim_papermule.co.uk_trim> wrote:
>Memo for people who find this thread in the USENET
>archive; the key phrase here is "inside-out objects"
>
>http://www.perlmonks.org/?node_id=219924
Oh, and since then, tons of other ones! See e.g. a recent one from our
Anno:
http://perlmonks.org/?node_id=599394
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 13:33:32 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: perl + script files from only one directory
Message-Id: <8hhs03lh5dtoc62uv3j9e6sv648194jtao@4ax.com>
On Thu, 29 Mar 2007 11:01:41 +0200, Reinhard Pagitsch <rprp@gmx.net>
wrote:
>> Once you have your .exe, you can operate on it with AS's exetype.
>>
>> exetype foo.exe WINDOWS
>
>Great, that I did not know. I will keep it in mind.
>Thanks to the authors of PAR and pp.
In the meanwhile I tried my own advice and discovered it "doesn't
work": since actually a program is written to a temporary location and
then (presumably) executed, using exetype would save the "first"
console window but not the one for the latter. Oh, well I don't know
if my explanation is understandable, but the point is: a console
window would pop up anyway.
OTOH the real solution is even simpler, since pp has a --gui switch to
avoid just that under Windows.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 14:58:43 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: perl continuation character
Message-Id: <7mms03h87jdcitnfo1e8sl5g9gnj8hmi0e@4ax.com>
On Fri, 30 Mar 2007 22:39:20 GMT, "Jürgen Exner"
<jurgenex@hotmail.com> wrote:
>>> What is a "continuation character"?
>>
>> Some languages see a newline as the end of a statement, so when you're
>> writing in one of those you need to escape the newline, usually with a
>> backslash, for multi-line statements. The escape character for those
>> languages is called the "continuation character" because it indicates
>> that the statement will continue onto the next line.
>
>You mean like for the 6502 assembler for example? I thought fixed format
>languages were a relict from the past...
*NIX shells are still like that.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 13:16:04 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: perl continuation character
Message-Id: <oatPh.55$yL1.12@trndny04>
Michele Dondi wrote:
> On Fri, 30 Mar 2007 22:39:20 GMT, "Jürgen Exner"
> <jurgenex@hotmail.com> wrote:
>
>>>> What is a "continuation character"?
>>>
>>> Some languages see a newline as the end of a statement, so when
>>> you're writing in one of those you need to escape the newline,
>>> usually with a backslash, for multi-line statements. The escape
>>> character for those languages is called the "continuation
>>> character" because it indicates that the statement will continue
>>> onto the next line.
>>
>> You mean like for the 6502 assembler for example? I thought fixed
>> format languages were a relict from the past...
>
> *NIX shells are still like that.
Ah, well, yeah, I guess so.
Although IMHO it is a stretch to call bash or csh or any of those a
programming language
jue
------------------------------
Date: Sat, 31 Mar 2007 16:57:50 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: perl continuation character
Message-Id: <elts03lt2c0a7mbh8bf968l7r92hdoalf9@4ax.com>
On Sat, 31 Mar 2007 13:16:04 GMT, "Jürgen Exner"
<jurgenex@hotmail.com> wrote:
>> *NIX shells are still like that.
>
>Ah, well, yeah, I guess so.
>Although IMHO it is a stretch to call bash or csh or any of those a
>programming language
Well, not that much. They're fairly complete. Well, maybe you've not
been shocked as I was, coming from M$-DOS batch files...
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 15:54:07 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: perl continuation character
Message-Id: <zuvPh.29606$x9.1526@edtnps89>
Jürgen Exner wrote:
> Michele Dondi wrote:
>>On Fri, 30 Mar 2007 22:39:20 GMT, "Jürgen Exner"
>><jurgenex@hotmail.com> wrote:
>>
>>>>>What is a "continuation character"?
>>>>Some languages see a newline as the end of a statement, so when
>>>>you're writing in one of those you need to escape the newline,
>>>>usually with a backslash, for multi-line statements. The escape
>>>>character for those languages is called the "continuation
>>>>character" because it indicates that the statement will continue
>>>>onto the next line.
>>>You mean like for the 6502 assembler for example? I thought fixed
>>>format languages were a relict from the past...
>>*NIX shells are still like that.
>
> Ah, well, yeah, I guess so.
> Although IMHO it is a stretch to call bash or csh or any of those a
> programming language
You better not say that on comp.unix.shell :-)
John
--
Perl isn't a toolbox, but a small machine shop where you can special-order
certain sorts of tools at low cost and in short order. -- Larry Wall
------------------------------
Date: 31 Mar 2007 10:04:22 -0700
From: "ChrisC" <christopher.m.collins@gmail.com>
Subject: Re: Perl package install dll problems
Message-Id: <1175360662.433424.41420@o5g2000hsb.googlegroups.com>
After talking to the inline-java package author, we discovered that by
using an earlier version of nmake (I was using from VS 2005, switched
to VS2003) it worked.
Maybe ActivePerl isn't built with VS 2005? Anyway, finally, it works
fine.
Chris
------------------------------
Date: Sat, 31 Mar 2007 08:25:01 -0700
From: Xiong Changnian <please@nospam.net>
Subject: Re: prototypes - use or not?
Message-Id: <please-F293CB.08250131032007@free.teranews.com>
In article <46098403$1@news.alcatel.com>,
"Dan Becker" <dcbecker@nospam-alcatel-lucent.com> wrote:
> Perl Best Practices (Conway), section 9.10, has a pretty clear statement
> that subroutine prototypes should not be used. Period.
The trouble with prototypes, as I see it, is that they may not do what
you expect -- depending, of course, on what you expect. Prototypes don't
do type checking; rather, they force types. I think it might be better
to write your code so as to supply the right type of param in the first
place.
In most cases, I believe, if you're thinking about prototypes, you'd be
better off checking params explicitly and writing good docs.
Prototypes doubtless have their uses and if you stick with this thread
long enough, you'll find an avid supporter. I'm not going to get into a
war over them. I do suggest that before you decide to use them, you
spend quite a bit of time learning exactly what they do and do not do.
--
Xiong Changnian
xiong102ATxuefangDOTcom
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Sat, 31 Mar 2007 08:11:59 -0700
From: Xiong Changnian <please@nospam.net>
Subject: Re: Shifting Away
Message-Id: <please-243B83.08115631032007@free.teranews.com>
In article <slrnf0s4vm.9s8.hjp-usenet2@yoyo.hjp.at>,
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
> It wasn't clear who you were blaming of "sloppy coding"....
Sorry. I guess I took it for granted that any reader would understand
what I meant. I'm not sure I can be more lucid but I'll try.
When you deliberately pass refs to params, you must explicitly deref
them inside the sub. Therefore, there is a bit of confusion involved
when saying that Perl passes all params as refs. It's true; but a little
bit deeper in the machinery, the ref is dereffed for you. That's
probably an inexact statement but that's not the issue. As you say,
Peter, it *is* call-by-ref, even if the syntax says you're just passing
a scalar.
(This distinction is important to me because I avidly pass refs as
params when it's reasonable to do so; and because my code is seriously
OO and all objects are refs.)
Now, this can be a useful thing or it can cause problems -- like any
feature of any tool. You can choose to see it as a bug to be worked
around or a feature to be used; and if it bites you, you can blame
yourself -- or, if you want to be bullheaded, blame Perl. In my last
post, I covered the fourth possibility, in which you use the feature to
good effect and give yourself a pat on the back.
I hope I haven't stepped into some fanatic defense of Perl here. I
*like* it; I think it's better than competing P*'s; and I wouldn't
recommend Ruby due to immaturity -- **IMHO**! I assume that everyone
here thinks Perl is a Good Thing -- otherwise, why be here?
Is there some shibboleth I must pronounce to bypass this rigorous
loyalty-checking? I'm not really interested in fighting over the
Rightness of Perl -- on either side. I just want to know how it works. I
come here to ask questions and learn. I'm not trying to rewrite the
docs.
--
Xiong Changnian
xiong102ATxuefangDOTcom
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Sat, 31 Mar 2007 10:30:55 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Shifting Away
Message-Id: <x7d52p2zww.fsf@mail.sysarch.com>
>>>>> "XC" == Xiong Changnian <please@nospam.net> writes:
XC> In article <slrnf0s4vm.9s8.hjp-usenet2@yoyo.hjp.at>,
XC> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
XC> When you deliberately pass refs to params, you must explicitly deref
XC> them inside the sub. Therefore, there is a bit of confusion involved
XC> when saying that Perl passes all params as refs. It's true; but a little
XC> bit deeper in the machinery, the ref is dereffed for you. That's
XC> probably an inexact statement but that's not the issue. As you say,
XC> Peter, it *is* call-by-ref, even if the syntax says you're just passing
XC> a scalar.
ok, let's try to clear up some stuff. first off all sub args are passed by
alias, not exactly by ref. it isn't deliberate or accidental, but all
the time. the callee has the aliases in @_ and can do with them what it
wants. the act of copying an alias is not dereferencing it but removing
the alias nature and making a copy of the original argument. it does not
break the alias which is still in @_. and i reiterate they are NOT refs
but aliases (similar to aliasing in foreach). you can't call ref on them
and get a ref type:
perl -le 'sub foo { print ref $_[0] } foo( 1 ) ;'
perl -le 'sub foo { print ref $_[0] } foo( [] ) ;'
ARRAY
XC> (This distinction is important to me because I avidly pass refs as
XC> params when it's reasonable to do so; and because my code is seriously
XC> OO and all objects are refs.)
refs are not aliases. you explicitly pass a ref since you want a real
ref to be used in the sub/method. you can't use @_ aliases as object or
other refs. so stop calling them refs.
XC> Now, this can be a useful thing or it can cause problems -- like any
XC> feature of any tool. You can choose to see it as a bug to be worked
XC> around or a feature to be used; and if it bites you, you can blame
XC> yourself -- or, if you want to be bullheaded, blame Perl. In my last
XC> post, I covered the fourth possibility, in which you use the feature to
XC> good effect and give yourself a pat on the back.
the only bug in in your understanding. @_ aliases are not refs. consider
this: when you assign (via indexing or shift) an alias from @_ to any
variable, it loses it alias nature. yet you can assign a ref to anything
else and it keeps its ref nature. @_ aliases are special. and one reason
they were made that way was for speed. it is much cheaper to push a list
of aliases onto a stack then to copy all of the arguments. and it allows
for the direct modification of the original arguments IF YOU WANT to do
that via aliases. if you don't you can always pass refs and copy those
as normal and modify away. YOUR CHOICE. in general it is always better
to pass refs yourself but there are some small cases where modifying via
aliases is a useful idea. not common but they exist.
XC> I hope I haven't stepped into some fanatic defense of Perl here. I
XC> *like* it; I think it's better than competing P*'s; and I wouldn't
XC> recommend Ruby due to immaturity -- **IMHO**! I assume that everyone
XC> here thinks Perl is a Good Thing -- otherwise, why be here?
you are not talking about the same thing so there is no fanatic
defense. you don't seem to understand aliases vs refs. that is the
problem, not perl.
XC> Is there some shibboleth I must pronounce to bypass this rigorous
XC> loyalty-checking? I'm not really interested in fighting over the
XC> Rightness of Perl -- on either side. I just want to know how it works. I
XC> come here to ask questions and learn. I'm not trying to rewrite the
XC> docs.
yes, you must come to an understanding of the actual topic first before
you flame away and babble incoherently. @_ aliases are not refs. you
think that because they refer to the original value that this is pass by
reference but it is not the same as most times you copy the args and
then they become pass by value. only a few subs should ever directly
modify their args via @_. and only a few more should directly access
@_. @_ is usually assigned to my vars or shifted (or both which can be
useful).
that is all.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 31 Mar 2007 16:03:43 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Shifting Away
Message-Id: <577f2vF2bvrpmU1@mid.dfncis.de>
Xiong Changnian <please@nospam.net> wrote in comp.lang.perl.misc:
> In article <572nr3F2bt8ohU1@mid.dfncis.de>,
> anno4000@radom.zrz.tu-berlin.de wrote:
>
> > ...it's harder to demonstrate than I thought.
>
> To recap, I understand you to claim that actual params can be clobbered
> within a called sub that shift-s.
Quite so.
> > sub x3 { shift() = 13 }
> >
> > doesn't compile...
>
> Well, here you're trying to assign to shift itself; I believe shift is
> never an lvalue.
Pardon the pedantry, but I'm not trying to assign to "shift itself",
but to the return value of the function "shift" or, if you will, the
result of the list operator "shift". In view of the existence of lvalue
subs and other operators (substr for instance) that allow assignment to
their results that isn't entirely unreasonable. As I said before, the
restriction is syntactical and rather arbitrary.
> > sub x1 { $_ = 13 for shift }
>
> That does indeed clobber the actual param. As I understand it, your code
> shifts off the first (or only) param -- by definition, not a list --
> then treats it as a single-element list; the first (and only) trip
> through the foreach loop, $_ is set to the first (and only) element of
> that list. And $_ is an alias to the thing itself.
>
> I guess if you try hard enough, you can break anything.
One-shot for loops aren't that exotic in Perl. With for loops over
lists you get aliasing, which means that the loop variable ($_ in
this case) becomes another name for the list element. Assignment to
the loop variable changes the list element, unlike assignment to
a copy. Sometimes aliasing is all you want, there is only a single
element to loop over. Fortunately, the meaning of "for" (but not
the non-word "foreach") covers the one-shot case nicely.
That is what happens in "sub x1 { $_ = 13 for shift }". If you will,
it is nothing but a syntactically acceptable form of "shift() = 13".
It proves that what shift() returns *is* an lvalue and can be used to
clobber the actual parameter. What makes the parameter safe is
assignment to a (usually) lexical variable in the sub body. That
creates a copy of the value that has nothing to do with the original
parameter.
> > I had intended to delete
> > that sentence and dodge an explanation...
>
> Why? This is what it's all about: finding the edges. Now, I'll be sure
> not to do *that*. Thank you.
Perl's "postmodern", non-orthogonal design entails lots and lots of
edge cases where the actual behavior can't be derived from general
principles, but is geared to the particular case. It is often
distracting and sometimes impossible to discuss all that may be
relevant to a topic.
Normally, the use of shift() in a sub means the sub is not going
to change the parameter in question. If the form is the standard
my $var = shift;
you *know* that, because the only original is gone and all the sub
has is a copy[1]. If shift() is used in other ways, you must look
closer.
Anno
[1] If I were to discuss all ramifications I'd have to mention the
possibility that the same parameter could appear a second time
in the argument list and the sub could still change that.
------------------------------
Date: Sat, 31 Mar 2007 14:22:52 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: What are OOP's Jargons and Complexities
Message-Id: <bfks03huuqhf3o4327ddagnsnkd7s9kdor@4ax.com>
On Thu, 29 Mar 2007 18:19:44 -0400, Lew <lew@nospam.lewscanon.com>
wrote:
>> please DO NOT EVER followup xah's posts into comp.lang.perl.misc. he is
>> not wanted there and is considered a troll. he hates perl so why he
>> crossposts there is a question. if you want to followup, post only in
>> your own group. keep him and his useless threads out of c.l.p.misc.
>
>We've heard similar reports about Xah Lee on other newsgroups as well.
He seems enthusiastic about Python, so I suppose he's not (considered)
a troll there. OTOH he often tries to raise flames between our
respective communities, without much success - which suggests people
are smarter than his pathetic attempts...
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 14:26:31 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: What are OOP's Jargons and Complexities
Message-Id: <oqks03h3h5tldjodga4and8ua3hej6a1uq@4ax.com>
On Fri, 30 Mar 2007 09:28:36 +0100, bugbear
<bugbear@trim_papermule.co.uk_trim> wrote:
>Er. How about
>
>public class test {
> public static void main(String[] args) {
> String a = "a string";
> String b = "another one";
> StringBuffer c = a + b;
> System.out.println(c);
> }
>}
Even better: pick one entry of your choice from
http://images.google.com/images?q=%22don%27t+feed+the+troll%22
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 31 Mar 2007 11:56:57 -0400
From: Lew <lew@nospam.lewscanon.com>
Subject: Re: What are OOP's Jargons and Complexities
Message-Id: <RPadne6QN55UGZPbnZ2dnUVZ_hKdnZ2d@comcast.com>
Arved Sandstrom wrote:
> "Timofei Shatrov" <grue@mail.ru> wrote in message
> news:460cc83a.2652073@news.readfreenews.net...
>> On Fri, 30 Mar 2007 06:48:05 GMT, "Mike Schilling"
>> <mscottschilling@hotmail.com>
>> tried to confuse everyone with this message:
>>
>>> Xah Lee wrote:
>>>
>>>> So, a simple code like this in normal languages:
>>>> becomes in Java:
>>> Only when written by someone almost entirely ignorant of Java.
>>>
>> Which is the state most people want to be in...
>
> Which based on what I've seen, is the state that most Java programmers are
> in. They'd have no idea why Mike said what he did.
what EVerrr!
-- Lew
------------------------------
Date: Sat, 31 Mar 2007 12:00:43 -0400
From: Lew <lew@nospam.lewscanon.com>
Subject: Re: What are OOP's Jargons and Complexities
Message-Id: <RPadnemQN54rGJPbnZ2dnUVZ_hKdnZ2d@comcast.com>
Michele Dondi wrote:
> Even better: pick one entry of your choice from
>
> http://images.google.com/images?q=%22don%27t+feed+the+troll%22
I pick <http://img371.imageshack.us/img371/8263/noah7ok6rh.jpg/>
-- Lew
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 287
**************************************
