[32447] in Perl-Users-Digest
Perl-Users Digest, Issue: 3714 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 14 14:09:23 2012
Date: Thu, 14 Jun 2012 11:09:09 -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 Thu, 14 Jun 2012 Volume: 11 Number: 3714
Today's topics:
Re: 3-arg open - was Re: Very Sluggish Code <rweikusat@mssgmbh.com>
Re: an effective script for grabbing and putting images <ben@morrow.me.uk>
Re: an effective script for grabbing and putting images <hjp-usenet2@hjp.at>
Re: an effective script for grabbing and putting images <ben@morrow.me.uk>
Re: new topic: I call length($<string>) and get number <justin.1203@purestblue.com>
Re: Odd behaviour on Mac OS X Lion <arjenbax@googlemail.com>
Re: Odd behaviour on Mac OS X Lion (Tim McDaniel)
Re: Odd behaviour on Mac OS X Lion <ben@morrow.me.uk>
Perl Protoypes <rodbass63@gmail.com>
Re: Perl Protoypes <devnull4711@web.de>
Re: Perl Protoypes <rodbass63@gmail.com>
Re: Perl Protoypes <tw+usenet@dionic.net>
Re: Perl Protoypes <rweikusat@mssgmbh.com>
Re: Perl Protoypes <rweikusat@mssgmbh.com>
Re: Perl Protoypes <ben@morrow.me.uk>
Re: Perl Protoypes <cwilbur@chromatico.net>
Re: Perl Protoypes <rweikusat@mssgmbh.com>
Re: Perl Protoypes <willem@toad.stack.nl>
Re: Perl Protoypes <vilain@NOspamcop.net>
Re: Perl Protoypes <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 13 Jun 2012 11:46:37 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: 3-arg open - was Re: Very Sluggish Code
Message-Id: <87txyfqyk2.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> "Dave Saville" <dave@invalid.invalid> writes:
[...]
>> Hi Ben, that's the second time I have seen you advocate 3-arg open. I
>> think I now understand using a variable for the filehandle but I fail
>> to see the difference between "<foo" and "<", "foo".
>
> Logically, the open mode and the pathname to open are two different
> things and putting them into the same string argument which either the
> compiler or the runtime environment then need to take apart again by
> parsing it wasn't a good idea:
Additional remark: Very likely, this idea came from the UNIX(*)
(Bourne) shell which does the same thing (and mostly uses the same
'open mode' characters). But while the shell provides a very useful
programming language, being able to use it without Extreme Pain[tm]
relies on users of the system exercising 'wise restraint' when
creating named objects in the file system, ie, deliberatly avoiding
names the parser of the shell might trip over. If this cannot be
guaranteed, eg, because these users have either really no idea how this
parser works or might even be trying to trick scripts into performing
unintended operations with the help of suitable filename arguments,
every filesystem name needs to be quoted before using it and this
'quoting' is something people either don't bother to do or get wrong
(and even if they don't, that's nothing but code working around the
limitations of some parser). If this is easily possible, such as with
'3-arg open' in Perl, it is much better to avoid the issue altogether,
at least for software supposed to be generally useful/ usable.
------------------------------
Date: Wed, 13 Jun 2012 11:46:03 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: an effective script for grabbing and putting images from or to a website
Message-Id: <bk7ma9-m1p2.ln1@anubis.morrow.me.uk>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Tue, 12 Jun 2012 17:52:43 -0600, Cal Dershowitz wrote:
> > On 06/12/2012 05:05 PM, Ben Morrow wrote:
>
> >> You should be aware that, although many sites put conventional
> >> extensions on their URLs, there is no particular reason why they
> >> should.
> >> Unless you know the sites you are using do (and will continue to do
> >> so),
> >> you should rather look at the Content-Type header returned and map that
> >> to an appropriate extension. You can do the mapping with a simple hash,
> >> or with the MIME::Types module, and you will need to switch from
> >> LWP::Simple to the full LWP::UserAgent to get hold of the Content-Type
> >> response header.
> >
> > ok. So if I'm writing a perl script to grab an image, I do not make
> > decisions about it based first on the extension, but what the html says
> > about the image, right?
>
> Nitpick, what (the) HTTP (Content-Type header) says about the image.
This is more than a nitpick, it's actually quite important. The header
which tells you what type of file the image is is not available until
*after* you've downloaded it. This means that if you want to save it in
a file with an appropriate extension, you need to put it in a temporary
file first and then rename it.
Ben
------------------------------
Date: Wed, 13 Jun 2012 13:44:32 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: an effective script for grabbing and putting images from or to a website
Message-Id: <slrnjtgv91.5g0.hjp-usenet2@hrunkner.hjp.at>
On 2012-06-13 10:46, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
>> On Tue, 12 Jun 2012 17:52:43 -0600, Cal Dershowitz wrote:
>> > ok. So if I'm writing a perl script to grab an image, I do not make
>> > decisions about it based first on the extension, but what the html says
>> > about the image, right?
>>
>> Nitpick, what (the) HTTP (Content-Type header) says about the image.
>
> This is more than a nitpick, it's actually quite important. The header
> which tells you what type of file the image is is not available until
> *after* you've downloaded it. This means that if you want to save it in
> a file with an appropriate extension, you need to put it in a temporary
> file first and then rename it.
No. The header is sent before the body, so the natural way to save a
file downloaded via HTTP is:
1) send request
2) read response header (now we know the content-type)
3) create/open file
4) read body and write to file.
Even if you can't for some reason do anything between reading the header
and body, we are talking about images here which are small compared to
RAM, so you can just:
1) send request
2) read entire response into memory
3) create/open file
4) save body to file
The important (and sometimes annoying) part isn't about saving the
resource. It's that you have to actually send a request! In general,
HTML doesn't tell you whether the target of a link is an HTML or PDF
document, a JPEG image or a ZIP archive. So even if you know that you
are only interested in specific content-types, you still have to request
all the resources and throw those away which you don't want (you can
trade-off number of requests vs. band-width by using HEAD requests).
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Wed, 13 Jun 2012 14:45:11 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: an effective script for grabbing and putting images from or to a website
Message-Id: <74ima9-iin.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2012-06-13 10:46, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> >> On Tue, 12 Jun 2012 17:52:43 -0600, Cal Dershowitz wrote:
> >> > ok. So if I'm writing a perl script to grab an image, I do not make
> >> > decisions about it based first on the extension, but what the html says
> >> > about the image, right?
> >>
> >> Nitpick, what (the) HTTP (Content-Type header) says about the image.
> >
> > This is more than a nitpick, it's actually quite important. The header
> > which tells you what type of file the image is is not available until
> > *after* you've downloaded it. This means that if you want to save it in
> > a file with an appropriate extension, you need to put it in a temporary
> > file first and then rename it.
>
> No. The header is sent before the body, so the natural way to save a
> file downloaded via HTTP is:
Well, yes. My point was that the OP's original program was using the
extension from the URL given in the HTML; if he were to switch to using
the content-type he would need to make the request before choosing the
filename.
> 1) send request
> 2) read response header (now we know the content-type)
> 3) create/open file
> 4) read body and write to file.
>
> Even if you can't for some reason do anything between reading the header
> and body, we are talking about images here which are small compared to
> RAM, so you can just:
>
> 1) send request
> 2) read entire response into memory
> 3) create/open file
> 4) save body to file
That is usually the case when using LWP in the obvious way. It is
certainly possible to get in between receipt of header and body, but not
entirely straightforward.
I wouldn't like to assume that a file sent from an arbitrary HTTP server
will fit into memory. *Probably* it will, but if you're intending to
write it to file in the end anyway it seems safer to do so immediately.
This provides the additional advantage of following the proper
write-close-rename idiom for making a file available atomically
(probably not important in this case, but it never does any harm).
> The important (and sometimes annoying) part isn't about saving the
> resource. It's that you have to actually send a request! In general,
> HTML doesn't tell you whether the target of a link is an HTML or PDF
> document, a JPEG image or a ZIP archive. So even if you know that you
> are only interested in specific content-types, you still have to request
> all the resources and throw those away which you don't want (you can
> trade-off number of requests vs. band-width by using HEAD requests).
Exactly.
Ben
------------------------------
Date: Wed, 13 Jun 2012 15:19:13 +0100
From: Justin C <justin.1203@purestblue.com>
Subject: Re: new topic: I call length($<string>) and get number of lines - code frag below - on MAC OS X 10.7
Message-Id: <14kma9-tk.ln1@zem.masonsmusic.co.uk>
On 2012-06-10, kquirici <kquirici@yahoo.com> wrote:
> Ah, I see what the problem was - I had %_ instead of $_.
>
> Thanks & Regards,
>
> Ken Quirici
But don't disregard what Ben suggested, it's better, clearer
and more concise than what you have. In addition, if you
don't implement better methods when they're pointed out to
you then the next time you have a problem and ask here you're
going to get the same "use the three argument open", and
"local $/ for slurping" rather than getting to the meat of
your problem.
open my $JOURNALTXT, "<", $inputfilename
or die "cannot open '$inputfilename': $!";
my $journalin;
{
local $/; # this sets $/ to undef
$journalin = <$JOURNALTXT>;
}
print "journal length: ", length($journalin), "\n";
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 13 Jun 2012 02:42:12 -0700 (PDT)
From: ilovelinux <arjenbax@googlemail.com>
Subject: Re: Odd behaviour on Mac OS X Lion
Message-Id: <52698375-d659-41fe-889c-3d7a65d41e87@v9g2000yqm.googlegroups.com>
On 11 jun, 08:54, Trudge wrote:
> I've been having some odd behaviour lately on our work computer running t=
he installed Apple Perl. I have the following few lines of code:
>
> #!/usr/bin/perl
> BEGIN
> {
> =A0 =A0 =A0 =A0 open (STDERR,">>$0-err.txt");
> =A0 =A0 =A0 =A0 print STDERR "\n",scalar localtime,"\n";
> }
>
> use strict;
> use warnings;
1) I would switch the BEGIN block and the use strict & warnings.
2) If, in the hashbang line, /usr/bin/perl is followed by a carriage
return (^M) the script will not run. That's why I *always* add a '-w'
to the hashbang line of Perl scripts:
#!/usr/bin/perl -w
That makes the script independent of the line endings.
------------------------------
Date: Wed, 13 Jun 2012 21:23:43 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Odd behaviour on Mac OS X Lion
Message-Id: <jrb0cv$2g3$1@reader1.panix.com>
In article <52698375-d659-41fe-889c-3d7a65d41e87@v9g2000yqm.googlegroups.com>,
ilovelinux <arjenbax@googlemail.com> wrote:
>On 11 jun, 08:54, Trudge wrote:
>> I've been having some odd behaviour lately on our work computer
>> running the installed Apple Perl. I have the following few lines of
>> code:
>>
>> #!/usr/bin/perl
...
>> use strict;
>> use warnings;
>
>1) I would switch the BEGIN block and the use strict & warnings.
Yes.
>2) If, in the hashbang line, /usr/bin/perl is followed by a carriage
>return (^M) the script will not run. That's why I *always* add a '-w'
>to the hashbang line of Perl scripts:
>#!/usr/bin/perl -w
>That makes the script independent of the line endings.
Please let me check to see if I understand correctly. I think the
idea is that UNIX-like kernels will look for "#!" as the first two
bytes, and if found, will skip any space characters immediately after
it, then read bytes up to a space character and use that as the name
of the executable. So if you have a bad line terminator on the first
line, the "[space]-w" will insulate the executable name from it so at
least the kernel will still get the correct executable and be able to
run it -- that is, instead of trying to exec /usr/bin/perl\r, it'll
run /usr/bin/perl. It may pass "-w\r" and maybe more characters as
the first command-line argument to Perl. "-w", then, is just because
you need a valid option (so you can type a space) that happens not to
be harmful.
Is that right?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 13 Jun 2012 23:12:28 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Odd behaviour on Mac OS X Lion
Message-Id: <crfna9-flp.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <52698375-d659-41fe-889c-3d7a65d41e87@v9g2000yqm.googlegroups.com>,
> ilovelinux <arjenbax@googlemail.com> wrote:
>
> >2) If, in the hashbang line, /usr/bin/perl is followed by a carriage
> >return (^M) the script will not run. That's why I *always* add a '-w'
> >to the hashbang line of Perl scripts:
> >#!/usr/bin/perl -w
> >That makes the script independent of the line endings.
>
> Please let me check to see if I understand correctly. I think the
> idea is that UNIX-like kernels will look for "#!" as the first two
> bytes, and if found, will skip any space characters immediately after
> it, then read bytes up to a space character and use that as the name
> of the executable. So if you have a bad line terminator on the first
> line, the "[space]-w" will insulate the executable name from it so at
> least the kernel will still get the correct executable and be able to
> run it -- that is, instead of trying to exec /usr/bin/perl\r, it'll
> run /usr/bin/perl. It may pass "-w\r" and maybe more characters as
> the first command-line argument to Perl. "-w", then, is just because
> you need a valid option (so you can type a space) that happens not to
> be harmful.
>
> Is that right?
Yes, with the additional subtlety that perl will interpret an argument
of "-w\r" correctly. A lot of programs wouldn't.
-- might be better, as a strictly do-nothing option.
Ben
------------------------------
Date: Wed, 13 Jun 2012 19:35:30 -0700 (PDT)
From: Nene <rodbass63@gmail.com>
Subject: Perl Protoypes
Message-Id: <552bfb24-4c83-4692-beb9-673b568b19c4@googlegroups.com>
Can somebody show me examples of prototypes used in Perl and why they are bad.
Please show me a bad example of protoypes and then show me the correct way of writing. Please use simple examples so that I can copy and paste your examples on my computer and run them my self.
I have read Tom's excellent note on prototypes but it's a little too advanced for me, I need to take baby steps for now, and then I'll go back to Tom's article on prototypes. TIA
usaims
------------------------------
Date: Thu, 14 Jun 2012 10:25:48 +0200
From: Frank Seitz <devnull4711@web.de>
Subject: Re: Perl Protoypes
Message-Id: <jrc76c$p36$1@news.albasani.net>
Nene wrote:
> Can somebody show me examples of prototypes used in Perl and why they are bad.
>
> Please show me a bad example of protoypes and then show me the correct way of writing. Please use simple examples so that I can copy and paste your examples on my computer and run them my self.
>
> I have read Tom's excellent note on prototypes but it's a little too advanced for me, I need to take baby steps for now, and then I'll go back to Tom's article on prototypes. TIA
>
> usaims
http://bit.ly/MCuTAy
Regards
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet | Web-, Database-, Unix-Development
Tel: +49 (0)176/78243503, Hermann-Rohwedder-Straße 16, D-25462 Rellingen
Blog: http://www.fseitz.de/blog
------------------------------
Date: Thu, 14 Jun 2012 04:45:24 -0700 (PDT)
From: Nene <rodbass63@gmail.com>
Subject: Re: Perl Protoypes
Message-Id: <d8e886fd-584c-4cdb-8db7-a77f69aea224@googlegroups.com>
On Thursday, June 14, 2012 4:25:48 AM UTC-4, Frank Seitz wrote:
> Nene wrote:
> > Can somebody show me examples of prototypes used in Perl and why they a=
re bad.
> >=20
> > Please show me a bad example of protoypes and then show me the correct =
way of writing. Please use simple examples so that I can copy and paste you=
r examples on my computer and run them my self.
> >=20
> > I have read Tom's excellent note on prototypes but it's a little too ad=
vanced for me, I need to take baby steps for now, and then I'll go back to =
Tom's article on prototypes. TIA
> >=20
> > usaims
>=20
> http://bit.ly/MCuTAy
I have that book too and read it, still a little above my head :-(
Can somebody explain to me what this code does? I'm more concerned
what the '$$' does and '$code->()'
# A handy shortcut for building a quick-and-dirty command-line interface
sub subcommand($$) {
my ($expected, $code) =3D @_;
if ($expected eq $ARGV[0]) {
shift @ARGV;
$code->();
exit;
}
}
>=20
> Regards
> Frank
> --=20
> Dipl.-Inform. Frank Seitz
> Anwendungen f=FCr Ihr Internet und Intranet | Web-, Database-, Unix-Devel=
opment
> Tel: +49 (0)176/78243503, Hermann-Rohwedder-Stra=DFe 16, D-25462 Rellinge=
n
>=20
> Blog: http://www.fseitz.de/blog
------------------------------
Date: Thu, 14 Jun 2012 12:56:05 +0100
From: Tim Watts <tw+usenet@dionic.net>
Subject: Re: Perl Protoypes
Message-Id: <l30pa9-eh5.ln1@squidward.local.dionic.net>
Nene wrote:
> On Thursday, June 14, 2012 4:25:48 AM UTC-4, Frank Seitz wrote:
>> Nene wrote:
>> > Can somebody show me examples of prototypes used in Perl and why they
>> > are bad.
>> >
>> > Please show me a bad example of protoypes and then show me the correct
>> > way of writing. Please use simple examples so that I can copy and paste
>> > your examples on my computer and run them my self.
>> >
>> > I have read Tom's excellent note on prototypes but it's a little too
>> > advanced for me, I need to take baby steps for now, and then I'll go
>> > back to Tom's article on prototypes. TIA
>> >
>> > usaims
>>
>> http://bit.ly/MCuTAy
>
> I have that book too and read it, still a little above my head :-(
>
> Can somebody explain to me what this code does? I'm more concerned
> what the '$$' does and '$code->()'
>
> # A handy shortcut for building a quick-and-dirty command-line interface
>
> sub subcommand($$) {
> my ($expected, $code) = @_;
> if ($expected eq $ARGV[0]) {
> shift @ARGV;
> $code->();
> exit;
> }
> }
>
Hi,
sub somesub($$)
means that somesub() is expecting 2 arguments, both scalars - note that
"scalar" includes refereneces to other types as in the example where $code
is reference to a subroutine (aka pointer to function in C).
$code->() calles the subroutine (or code block) whose reference is stored in
$code, in this case it is called with no arguments.
HTH
Tim
--
Tim Watts
------------------------------
Date: Thu, 14 Jun 2012 13:34:07 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Perl Protoypes
Message-Id: <87mx46139c.fsf@sapphire.mobileactivedefense.com>
Frank Seitz <devnull4711@web.de> writes:
> Nene wrote:
>> Can somebody show me examples of prototypes used in Perl and why they are bad.
>>
>> Please show me a bad example of protoypes and then show me the correct way of writing. Please use simple examples so that I can copy and paste your examples on my computer and run them my self.
>>
>> I have read Tom's excellent note on prototypes but it's a little too advanced for me, I need to take baby steps for now, and then I'll go back to Tom's article on prototypes. TIA
>>
>> usaims
>
> http://bit.ly/MCuTAy
In theory, that's a valid argument. In practice, however, it is
totally futile because everything said in there applies to the builtin
operators of Perl as well: It is not possible to know how the
arguments given to any operator will be evaluated without knowing the
'signature' of this operator. This problem is - of course - multiplied
when the same is also true for user-defined subroutines but
nevertheless 'by design' part of Perl. The fact that this text isn't
an all-out criticism of this design descision but claims to be about
'subroutine prototypes' makes it somewhat disingenious.
Considering that Perl works the way it does in this respect,
subroutine prototypes have one useful function: They can enable the
compiler to throw an error when a subroutine is called with less
arguments than required. It is up to the person who writes the code to
decide it this is more important than being able to use an @array to
pass arguments. In my opinion, it is.
------------------------------
Date: Thu, 14 Jun 2012 14:37:47 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Perl Protoypes
Message-Id: <87haue10b8.fsf@sapphire.mobileactivedefense.com>
Tim Watts <tw+usenet@dionic.net> writes:
[...]
> sub somesub($$)
>
> means that somesub() is expecting 2 arguments, both scalars
It doesn't. That's the exact pitfall Conway wrote about: It means that
somesub takes two arguments and that both will be evaulated in scalar
context.
------------------------------
Date: Thu, 14 Jun 2012 16:51:43 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl Protoypes
Message-Id: <ftdpa9-h412.ln1@anubis.morrow.me.uk>
Quoth Nene <rodbass63@gmail.com>:
> Can somebody show me examples of prototypes used in Perl and why they are bad.
>
> Please show me a bad example of protoypes and then show me the correct
> way of writing. Please use simple examples so that I can copy and paste
> your examples on my computer and run them my self.
The problem with prototypes is that they change the context of the
arguments passed to the function, which is often unexpected. For
instance, if you have a function which expects four arguments, and you
write it
sub foo ($$$$) { ... }
then a call like
my @args = (1, 2, 3, 4);
foo @args;
will not work: @args is evaluated in scalar context, returning a single
argument of 4 (the length of the array), and the function call throws a
compile-time error because it wanted 4 arguments. The same would apply
to a call like
foo map $_ + 1, 1, 2, 3, 4;
or any other situation where the user is trying to build a list of
arguments rather than supplying them literally.
There are some circumstances where prototypes are useful. For instance,
Scalar::Util::reftype is prototyped ($); this is extremely useful, since
it means something like
reftype $x eq "HASH"
parses as
reftype($x) eq "HASH"
rather than
reftype($x eq "HASH")
The trick is to balance the utility of the prototype against the
possible confusion caused by changing the way the arguments are
interpreted; IMHO, it's better to avoid prototypes unless your function
is very similar to a builtin which has one. So, 'reftype' is very
similar to the builtin 'ref', so someone calling it would probably
expect it to be prototyped the same way; for some other random function
of one argument it might well be more confusing rather than less.
The other issue which often seems to confuse people is that method calls
don't take any notice of prototypes. This means that if you are defining
a sub which is to be called as a method there is no point whatever
giving it a prototype, and in fact it would be very confusing to give it
one.
As ever, what you need to do is try to put yourself in the shoes of the
person calling your function: how will they expect it to behave? The
more you can do to reduce the element of surprise, the better, since it
makes it that bit less likely someone will make a mistake.
Ben
------------------------------
Date: Thu, 14 Jun 2012 11:45:40 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Perl Protoypes
Message-Id: <87boklyk0r.fsf@new.chromatico.net>
>>>>> "N" == Nene <rodbass63@gmail.com> writes:
N> Can somebody show me examples of prototypes used in Perl and why
N> they are bad.
They aren't bad. They are just not what programmers who are familiar
with C and C-like languages think. In C, prototypes are how the
compiler knows how many arguments a function takes and what types they
are. This is essential to C's design. So programmers new to Perl
coming from other languages start out by writing prototypes because they
are necessary in other languages. This is a mistake.
N> Please show me a bad example of protoypes and then
N> show me the correct way of writing. Please use simple examples so
N> that I can copy and paste your examples on my computer and run
N> them my self.
At your level of understanding, I think the best advice is to not use
protoptyes at all and not worry about them until you've got a couple
thousand lines of code underneath your belt.
For instance,
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Thu, 14 Jun 2012 17:40:36 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Perl Protoypes
Message-Id: <8762ataltn.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Nene <rodbass63@gmail.com>:
>> Can somebody show me examples of prototypes used in Perl and why they are bad.
>>
>> Please show me a bad example of protoypes and then show me the correct
>> way of writing. Please use simple examples so that I can copy and paste
>> your examples on my computer and run them my self.
>
> The problem with prototypes is that they change the context of the
> arguments passed to the function, which is often unexpected. For
> instance, if you have a function which expects four arguments, and you
> write it
>
> sub foo ($$$$) { ... }
>
> then a call like
>
> my @args = (1, 2, 3, 4);
> foo @args;
>
> will not work:
It can be made to work by using &foo(@args).
[...]
> There are some circumstances where prototypes are useful. For instance,
> Scalar::Util::reftype is prototyped ($); this is extremely useful, since
> it means something like
>
> reftype $x eq "HASH"
>
> parses as
>
> reftype($x) eq "HASH"
>
> rather than
>
> reftype($x eq "HASH")
That's the same 'I want to have my cake AND eat it' argumentation as
in the Conway text: Either signature-depdendent context or - even more
user intransparent - signature dependent precedence are a good thing,
then, they are a good thing and users just have to be aware of the
signatures of all subroutines/ operators they are using. Or they are a
bad thing and then, they are a bad thing, regardless of 'subroutine or
builtin' and certainly regardless of any conjectures someone might
have about other people's expections.
------------------------------
Date: Thu, 14 Jun 2012 16:55:40 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Perl Protoypes
Message-Id: <slrnjtk5sc.2rfn.willem@toad.stack.nl>
Rainer Weikusat wrote:
) That's the same 'I want to have my cake AND eat it' argumentation as
) in the Conway text: Either signature-depdendent context or - even more
) user intransparent - signature dependent precedence are a good thing,
) then, they are a good thing and users just have to be aware of the
) signatures of all subroutines/ operators they are using. Or they are a
) bad thing and then, they are a bad thing, regardless of 'subroutine or
) builtin' and certainly regardless of any conjectures someone might
) have about other people's expections.
That's the same black-and white reasoning that inflicted
'everything is an object' java upon the world.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Thu, 14 Jun 2012 10:40:32 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: Perl Protoypes
Message-Id: <vilain-5E32E8.10403114062012@news.individual.net>
In article <87boklyk0r.fsf@new.chromatico.net>,
Charlton Wilbur <cwilbur@chromatico.net> wrote:
> >>>>> "N" == Nene <rodbass63@gmail.com> writes:
>
> N> Can somebody show me examples of prototypes used in Perl and why
> N> they are bad.
>
> They aren't bad. They are just not what programmers who are familiar
> with C and C-like languages think. In C, prototypes are how the
> compiler knows how many arguments a function takes and what types they
> are. This is essential to C's design. So programmers new to Perl
> coming from other languages start out by writing prototypes because they
> are necessary in other languages. This is a mistake.
>
> N> Please show me a bad example of protoypes and then
> N> show me the correct way of writing. Please use simple examples so
> N> that I can copy and paste your examples on my computer and run
> N> them my self.
>
> At your level of understanding, I think the best advice is to not use
> protoptyes at all and not worry about them until you've got a couple
> thousand lines of code underneath your belt.
>
> For instance,
I came from FORTRAN some 35 years ago where the compiler did multiple
passes to ensure that a subroutine declared with 3 arguments got 3
arguments when it was called. I've always felt that Pascal was upside
down in that the subroutines and functions had to be before the main
code block.
In the assembly languages I learned, it was the caller's responsibility
to call a subroutine with the proper arguments on the stack. Or badness
happened.
Maybe declaring a prototype was something that C did to keep from having
to parse the code more than once. That way compile-time errors in the
same file could be flagged. But I've never written a compiler, so what
do I know.
I'm used to a language where the person writing the code is responsible
for doing it right or wrong. I document the hell out of blocks and
subroutines describing each argument and type before any actual code.
phpDocument actually enforces this coding practice. So far, the perl
I've written has been without prototypes but documented up the ying-yang
so that I know what's being passed to what, now and 6 months from now.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
------------------------------
Date: Thu, 14 Jun 2012 19:05:50 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Perl Protoypes
Message-Id: <871ulhahvl.fsf@sapphire.mobileactivedefense.com>
Willem <willem@toad.stack.nl> writes:
> Rainer Weikusat wrote:
> ) That's the same 'I want to have my cake AND eat it' argumentation as
> ) in the Conway text: Either signature-depdendent context or - even more
> ) user intransparent - signature dependent precedence are a good thing,
> ) then, they are a good thing and users just have to be aware of the
> ) signatures of all subroutines/ operators they are using. Or they are a
> ) bad thing and then, they are a bad thing, regardless of 'subroutine or
> ) builtin' and certainly regardless of any conjectures someone might
> ) have about other people's expections.
>
> That's the same black-and white reasoning that inflicted
> 'everything is an object' java upon the world.
Given that I'm not James Gosling and was neither writing about OO
concepts nor Java, it trivially isn't. Also, I wasn't really making an
argument, just pointing out that "it's good where I like it and bad
where I don't" isn't really an opinion, more of a gut feeling based on
gut estimates. Especially if it is also based on things statements
which simply aren't true: There is no 'uniform' way to pass arguments
in Perl, it always depends on the signature of the called thing. There
used to be such a thing in older versions of Perl but this just meant
that 'builtin operators' could do things user-defined subroutines
couldn't do. In Perl5, user-defined subroutines can be completely as
bizarrely behaving 'syntax hand-optimized for the taste of the author'
entities as the builtin operators already were. The interesting
question is 'Can this facility for punishing the uninitiated'
actually put to some more productive use than that?
------------------------------
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 3714
***************************************
