[33054] in Perl-Users-Digest
Perl-Users Digest, Issue: 4330 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Dec 17 11:09:17 2014
Date: Wed, 17 Dec 2014 08:09:04 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 17 Dec 2014 Volume: 11 Number: 4330
Today's topics:
Re: Both substitute and filter <whynot@pozharski.name>
Re: Both substitute and filter <bauhaus@futureapps.invalid>
Re: Both substitute and filter <rweikusat@mobileactivedefense.com>
Re: Both substitute and filter <rweikusat@mobileactivedefense.com>
Re: Both substitute and filter (Seymour J.)
Re: Both substitute and filter (Seymour J.)
Re: Both substitute and filter (Seymour J.)
Re: Both substitute and filter <bauhaus@futureapps.invalid>
Re: Both substitute and filter <bauhaus@futureapps.invalid>
Re: Both substitute and filter <stevem_@nogood.com>
Re: Both substitute and filter <rweikusat@mobileactivedefense.com>
Re: Can you point me in the right direction - accessing <jblack@nospam.com>
Re: Help needed on Regular Expressions <source@netcom.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 16 Dec 2014 10:10:02 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Both substitute and filter
Message-Id: <slrnm8vq6q.aga.whynot@orphan.zombinet>
with <8ch2mb-mbb.ln1@news.rtij.nl> Martijn Lievaart wrote:
> On Mon, 15 Dec 2014 06:03:42 +0000, Tim McDaniel wrote:
>> In article <8fltlb-ndq.ln1@news.rtij.nl>,
>> Martijn Lievaart <m@rtij.nl.invlalid> wrote:
*SKIP*
>> I also don't like substr in Perl. (The current code uses it, in
>> fact, and I'd like to lobby against it.)
> Why not. substr is a lot faster than using regexps.
> mmmmm.
>
> @sources = ("hi", "there", "TARGET23", "hello", "TARGETblarg", "world");
> @results = ()
> for (@sources) {
> push @results, substr($_, 6) if (substr($_, 0, 6) eq 'TARGET');
> }
>
> Could be by far the fastest of the bunch, even if it is the least
> 'Perlish'.
Your 'a lot faster' counts for 5%:
#!/usr/bin/perl
use strict;
use warnings;
use Benchmark qw{ cmpthese timethese };
my @sources = qw/ hi there TARGET23 hello TARGETblarg world /;
my @results;
cmpthese timethese -5, {
code00 => sub {
@results = ();
for (@sources) { push @results, substr $_, 6 if m/^TARGET/ } },
code01 => sub {
@results = ();
for (@sources) { push @results, substr $_, 6 if 'TARGET' eq substr $_, 0, 6 } },
code02 => sub {
@results = ();
for (@sources) { push @results, substr $_, 6 if !index $_, 'TARGET' } },
code03 => sub {
@results = ();
for (@sources) { push @results, m/^TARGET(.+)/ } },
};
__END__
Benchmark: running code00, code01, code02, code03 for at least 5 CPU seconds...
code00: 6 wallclock secs ( 5.52 usr + 0.00 sys = 5.52 CPU) @ 314646.92/s (n=1736851)
code01: 5 wallclock secs ( 5.22 usr + 0.00 sys = 5.22 CPU) @ 332730.08/s (n=1736851)
code02: 6 wallclock secs ( 5.10 usr + 0.00 sys = 5.10 CPU) @ 408142.35/s (n=2081526)
code03: 4 wallclock secs ( 5.26 usr + 0.00 sys = 5.26 CPU) @ 275166.16/s (n=1447374)
Rate code03 code00 code01 code02
code03 275166/s -- -13% -17% -33%
code00 314647/s 14% -- -5% -23%
code01 332730/s 21% 6% -- -18%
code02 408142/s 48% 30% 23% --
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Tue, 16 Dec 2014 11:47:56 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: Both substitute and filter
Message-Id: <m6p2k8$e15$1@dont-email.me>
On 15.12.14 18:45, Rainer Weikusat wrote:
>> The balance could be between knowledge of implicit features of Perl
>> and boring verbosity (even when avoiding redundancy). Consider knowledge
>> about when an initial assignment to a variable is necessary according
>> as it was introduced with “our”, “local”, or “my”, or none of these, etc.,
>> depending possibly on the calling/eval environment (cf. anonymous
>> subs, do).
>
> my @array; (or my %hash;)
>
> creates a container object. Because no information has been (or could
> have been) provided regarding its contents, it must obviously be an empty
> object.
Or undefined, which by itself hardly means "empty object"; see below.
Hence, "obviously" seems not the word that characterizes what is going on.
> Assigning a type-less empty list to a container object (surely a specific
> Perl feature(!)) clears the current contents of the container. Since
> there are none, the whole construct is just an exercise in obfuscation
> which will - at best - confuse people who aren't very familiar with
> Perl ("Surely, if it's in the code, it must be good for something!?!").
Consider this for contrast:
use warnings;
my $sclr; warn $sclr;
my @ary; warn @ary;
Perl reacts differently to lines 2 and 3 for various reasons, one being
that “my” means different things in the presence of “$” and “@”. At least,
to any reader other than the Perl interpreter, or the Perl specialist.
References to a number of features are needed to explain the matter.
That's history.
(History just needs to be accepted by the working programmer, but
relived and perpetuated?)
Continuing,
use strict 'vars'; warn $sclr->{'foo'};
no strict 'vars'; warn $ary->{'foo'};
The oddities become strikingly visible if you switch $sclr and $ary,
since now the program will be rejected by the interpreter even though
the syntax is the very same!
Features of Perl are in effect here that, while receiving little
emphasis in code are well worth knowing, because there is no other way
of tackling these artifacts of Perl. On the other hand, their
explanations run the risk of exponential growth in complexity with
every reference to another feature. Understandably, then, programmers
might refuse to like all these special cases, and so use redundant
non-Perlish code consistently, code that most of the time is between
harmless and wasteful. One might eventually arrive at sufficient
knowledge of Perl to avoid that. However, not by just consulting
`perldoc -f my`.
Imagine declaration and initialization of objects simplified in Perl 6
to the extent that one always first (in time) declares something, then
(re-)initializes it, and then uses it. Would Perl 6 be capable of
rewriting a Perl 5 program to become like that?
------------------------------
Date: Tue, 16 Dec 2014 15:26:53 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Both substitute and filter
Message-Id: <87lhm7booy.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> On 15.12.14 18:45, Rainer Weikusat wrote:
>>> The balance could be between knowledge of implicit features of Perl
>>> and boring verbosity (even when avoiding redundancy). Consider knowledge
>>> about when an initial assignment to a variable is necessary according
>>> as it was introduced with “our”, “local”, or “my”, or none of these, etc.,
>>> depending possibly on the calling/eval environment (cf. anonymous
>>> subs, do).
>>
>> my @array; (or my %hash;)
>>
>> creates a container object. Because no information has been (or could
>> have been) provided regarding its contents, it must obviously be an empty
>> object.
>
> Or undefined, which by itself hardly means "empty object"; see below.
> Hence, "obviously" seems not the word that characterizes what is going
> on.
That's a mental model some people carry around with them (as rather
useless baggage) but in this case (and in many others, such as 'objects
with static storage duration' in C, instances of classes which have a
default constructor in C++, class member variables in Java) this model
doesn't model reality: There is no such thing as 'an undefined variable'
in Perl as 'All data in Perl is a scalar, an array of scalars, or a hash
of scalars.' Considering that @array is obviously (see sigil) neither a
scalar nor a hash of scalars, it must be an array of scalars (of length
0).
>> Assigning a type-less empty list to a container object (surely a specific
>> Perl feature(!)) clears the current contents of the container. Since
>> there are none, the whole construct is just an exercise in obfuscation
>> which will - at best - confuse people who aren't very familiar with
>> Perl ("Surely, if it's in the code, it must be good for something!?!").
>
> Consider this for contrast:
>
> use warnings;
> my $sclr; warn $sclr;
> my @ary; warn @ary;
>
> Perl reacts differently to lines 2 and 3 for various reasons, one being
> that “my” means different things in the presence of “$” and “@”.
It always means the same thing: Create a lexically scoped object of some
type. But $sclr means something other than @sclr would mean: It's a
scalar and not an array. Initially, a scalar is said to have no
value. This means it will behave like an appropriately typed 'null
value' in any rvalue context using it. Some people feel strongly that
this is not how it should be done, hence, it is possible to _request_
that a warning is printed whenever an undefined value is implicitly
converted to a typed 'null value' such as an empty string or an integer
with value 0. Whether or not this is actually useful is a matter of
opinion: I haven't (and won't ever) enable this particular warning
because the odd error this may catch is far less common than all
spurious code which would need to be written just to accomodate the
interpreter.
In the given context, that is - however - completely besides the point
because we were discussion explicitly clearing the contents of empty
arrays: () is a literal expression denoting an empty list and not an
array constructor.
[...]
> Continuing,
>
> use strict 'vars'; warn $sclr->{'foo'};
> no strict 'vars'; warn $ary->{'foo'};
>
> The oddities become strikingly visible if you switch $sclr and $ary,
> since now the program will be rejected by the interpreter even though
> the syntax is the very same!
Congratulations! You've just experimentally determined something
explained in the first section of the 'Perl data types' documentation
(it can hardly become more 'Perl 101' than that): Objects are typed
(they're either scalars, arrays or hashes) and the type is denoted by a
sigil ($, @ or %). Hence,
$sclr->{foo}
access the scalar $sclr created above and
$ary->{foo}
- strangely, considering the syntax is exactly the same - accesses the
scalar $ary, hitherto undeclared and hence rejected in strict mode. That
there's accidentally a declared array with the same name doesn't matter.
------------------------------
Date: Tue, 16 Dec 2014 15:40:30 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Both substitute and filter
Message-Id: <87d27jbo29.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Georg Bauhaus <bauhaus@futureapps.invalid> writes:
[...]
>> Continuing,
>>
>> use strict 'vars'; warn $sclr->{'foo'};
>> no strict 'vars'; warn $ary->{'foo'};
[...]
> Congratulations!
[...]
As a postscriptum: I apologize for the sarcasm but this is TOO surreal
for me.
------------------------------
Date: Tue, 16 Dec 2014 11:08:49 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Both substitute and filter
Message-Id: <54905911$3$fuzhry+tra$mr2ice@news.patriot.net>
In <4jtjw.1006660$412.892157@fx30.iad>, on 12/14/2014
at 08:19 PM, Steve May <stevem_@nogood.com> said:
>Pointless from a strictly required standpoint, mostly yes.
>For self documentation standpoint, ease of reading, and some
>specific cases I'm not so sure.
Shirley a comment would satisfy that concern.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 16 Dec 2014 11:14:38 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Both substitute and filter
Message-Id: <54905a6e$1$fuzhry+tra$mr2ice@news.patriot.net>
In <m6i0ca$aja$1@speranza.aioe.org>, on 12/13/2014
at 07:26 PM, gamo <gamo@telecable.es> said:
>I was dreaming about the problem and I doubt anything can beat:
>for (@sources){
> next unless ( /^TARGET/ );
> s/^TARGET//;
> push @results, $_;
>}
What's wrong with this?
for (@sources){
next unless ( s/^TARGET//);
push @results, $_;
}
Superficially it should work and be faster.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 16 Dec 2014 11:26:20 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Both substitute and filter
Message-Id: <54905d2c$4$fuzhry+tra$mr2ice@news.patriot.net>
In <m6n47h$bcl$1@dont-email.me>, on 12/15/2014
at 06:03 PM, Georg Bauhaus <bauhaus@futureapps.invalid> said:
>The balance could be between knowledge of implicit features of Perl
>and boring verbosity
I don't see a difference in boring verbosity between the two:
my @array; # don't forget that it's emtpy!
my @array = ()
I consider the first to be better form, and Perl isn't even my native
language.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 16 Dec 2014 22:17:39 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: Both substitute and filter
Message-Id: <m6q7gv$jmq$1@dont-email.me>
On 16.12.14 16:26, Rainer Weikusat wrote:
> Considering that @array is obviously (see sigil) neither a
> scalar nor a hash of scalars, it must be an array of scalars (of length
> 0).
By itself, @array is just the name of an array. Anything else needs to
be known an is called into question: when the question is whether all
Perl text of the form
that-Perl-reserved-word [@%$]Name-word;
creates an object or not, and whether or not that is obvious.
>> Consider this for contrast:
>>
>> use warnings;
>> my $sclr; warn $sclr;
>> my @ary; warn @ary;
>>
>> Perl reacts differently to lines 2 and 3 for various reasons, one being
>> that “my” means different things in the presence of “$” and “@”.
>
> It always means the same thing: Create a lexically scoped object of some
> type.
Right. But
our $sclr; our @ary;
might require “local” in addition to “our”. I know there is no
problem finding the correct explanation. The above might require “= …;”,
though. Which is why people are not entirely unreasonable if they
just put some innocuous assignments with “my @ary”, too, even when that's
against purity, and even when doing it is caused by not knowing all the
ways in which “my” is different, semantically. Not knowing “my”, one might
say, and `perldoc -f my` is just a pointer to some more pointers into the
Perl reference.
>> Continuing,
>>
>> use strict 'vars'; warn $sclr->{'foo'};
>> no strict 'vars'; warn $ary->{'foo'};
>>
>> The oddities become strikingly visible if you switch $sclr and $ary,
>> since now the program will be rejected by the interpreter even though
>> the syntax is the very same!
>
> Congratulations! You've just experimentally determined something
> explained in the first section of the 'Perl data types' documentation
> (it can hardly become more 'Perl 101' than that): Objects are typed
> (they're either scalars, arrays or hashes) and the type is denoted by a
> sigil ($, @ or %). Hence,
>
> $sclr->{foo}
>
> access the scalar $sclr created above and
>
> $ary->{foo}
>
> - strangely, considering the syntax is exactly the same - accesses the
> scalar $ary, hitherto undeclared and hence rejected in strict mode. That
> there's accidentally a declared array with the same name doesn't matter.
Presence of sigil-carrying names and their other-sigil-carrying variations
matters to the programmer who thinks in terms of "natural" names rather
than the object designator forming constructs that Perl is actually using.
The latter capacity has its uses, but is undeniably a little complex.
(Just like SNOBOL-4's.)
Would you agree that there is Perl text where
(a) $xyz depends on both sigil *and* context, and that
(b) it takes a few sentences and mentions and references to clarify
what is simply not immediately present in that syntax in spite
of the sigil?
(Another gotcha is typing “$abc-[0]” and similar, i.e. missing “>”.
All the typedness of objects will at best trigger warnings.)
"Accidentally" puts it nicely: the whole business of sigils has become more
magical and obscure ever since the introduction of references so that it takes
a bit of apparatus and learning to think like Perl. (And people say that C++
is complex.) Of course, everyone who has learned all about “*” (Perl 4)
or "all the rest" (Perl 5) will have a huge advantage. Not to mention Perl
guts. But that's the problem: if it is so advantageous to know Perl
from inwards, or even "just" the reference docs, then what good is that
outwards knowledge of Perl?
In the presence of the complexity outlined, a desire to simplify by just
initializing expressly, visibly, seems understandable to me.
I don't do it, most of the times, but for example,
my ($xyz, ...) = (0, ...);
and subsequent
++$xyz;
is just more clear and less bragging IMHO than implicit referral
to Perl's default way for $xyz to be evaluated as 0 of the proper type.
------------------------------
Date: Tue, 16 Dec 2014 22:35:05 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: Both substitute and filter
Message-Id: <m6q8hl$o2t$1@dont-email.me>
On 16.12.14 17:26, Shmuel (Seymour J.) Metz wrote:
> In <m6n47h$bcl$1@dont-email.me>, on 12/15/2014
> at 06:03 PM, Georg Bauhaus <bauhaus@futureapps.invalid> said:
>
>> The balance could be between knowledge of implicit features of Perl
>> and boring verbosity
>
> I don't see a difference in boring verbosity between the two:
>
> my @array; # don't forget that it's emtpy!
> my @array = ()
>
> I consider the first to be better form, and Perl isn't even my native
> language.
O.K., if you count comments as the same verbosity as that of other
source text. There can be followup questions about style like
what if you almost always need a list in the first place, as in
my @a1 = (1, 2, 3);
my @a2 = ();
foo(\ @a1);
...
$a2[...] = ,,, $a1[...] ...;
...
I still wouldn't use (), but I do not find it so objectionable.
------------------------------
Date: Tue, 16 Dec 2014 21:36:28 -0800
From: Steve May <stevem_@nogood.com>
Subject: Re: Both substitute and filter
Message-Id: <yD8kw.352459$W25.293766@fx02.iad>
On 12/16/2014 08:08 AM, Shmuel (Seymour J.) Metz wrote:
> In <4jtjw.1006660$412.892157@fx30.iad>, on 12/14/2014
> at 08:19 PM, Steve May <stevem_@nogood.com> said:
>
>> Pointless from a strictly required standpoint, mostly yes.
>
>> For self documentation standpoint, ease of reading, and some
>> specific cases I'm not so sure.
>
> Shirley a comment would satisfy that concern.
>
Ah... well if that's what you prefer.
Not specific to the use of my @array = (); but consider:
sub opaque {
my $args = shift;
my @e = @{$args->{'p'}}; # 'p' is pachyderms, 'e' stands for elephants
my @d = @{$args->{'c'}}; # 'c' is canines, 'd' stands for dogs
}
as opposed to:
sub easier {
my $args = shift;
my @elephants = @{$args->{'pachyderms'}};
my @dogs = @{$args->{'canines'}};
}
The choice of variable names is more verbose, but certainly more
understandable, no in-line comments needed.
Now think about
sub faster_execution {
my $string;
my @array;
my %hash;
}
which requires me to squint mightily at the symbols, vs
sub faster_execution_but_cluttered {
my $string; # an empty string
my @array; # an empty array
my %hash; # an empty hash
}
which requires me to read a bunch of stuff, vs
sub faster_comprehension_for_me {
my $string = '';
my @array = ();
my %hash = ();
}
The point being that (for me) I find it easier to style my code so that
in line comments are rarely required since the style itself lends itself
to understanding what is happening.
The form my @array = (); scans very quickly for me. I do not have to
read a comment, I don't even have to look very closely at the variable
name symbol to know exactly what the variable is. Yes, yes, I'm taking a
hit in execution time in making the assignment, but with today's
machines I'm not going to lose sleep over it.
Anyway, it works for me. It may annoy another Perl programmer, but I
find it hard to believe any competent person would not understand what
the variables are.
In my book, the simplest easiest code is the best code. It may not be
the fastest, coolest, most succinct, or sexiest. But if it is easy for
me to understand and looks too dirt simple to work, yet does what it is
supposed to do: Perfect.
Might even approach elegance. :-)
###############
It's been interesting to watch all the responses to my original
inadvertent launch of this sub-thread.
Of all the responses, Ranier wrote the most useful to me (thank you) as
he made me stop and examine my thinking. I'm looking at the issue with a
different set of filters/needs, but he is technically correct as he is
so often.
Surprisingly, Ranier didn't mention the execution speed hit for
needlessly assigning an empty array though there _is_ one according to
my testing.
Some of the other responses were too much work for me to parse.
#################
Perl's motto is on the cover of Programming Perl 3rd Edition:
"There's More Than One Way To Do It"
To a degree, I have to wonder if we haven't lost sight of a few other
fundamental concepts from the book above:
"Perl is a language for getting your job done"
"Any level of language proficiency is acceptable in Perl culture. We
won't send the language police after you. A Perl script is "correct" if
it gets the job done before your boss fires you."
"With Perl you're free to do The Right Thing, however you care to define
it."
Some of that needs to be tempered with reason, of course.
And there are always new and better ways to do things.
But still.....
\s
------------------------------
Date: Wed, 17 Dec 2014 15:32:04 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Both substitute and filter
Message-Id: <87d27ixpfv.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> On 16.12.14 16:26, Rainer Weikusat wrote:
>> Considering that @array is obviously (see sigil) neither a
>> scalar nor a hash of scalars, it must be an array of scalars (of length
>> 0).
>
> By itself, @array is just the name of an array.
By itself, @array is a sequence of graphemes and any meaning which might
be associated with that depends on a certain context supplying an
interpretation. In case of the given context, your apparent assumption
- 'something like an object with automatic storage duration in C, ie,
reserved storage of size XXX whose contents are indeterminate' - is
wrong and @array refers to a Perl array.
[...]
>>> Consider this for contrast:
>>>
>>> use warnings;
>>> my $sclr; warn $sclr;
>>> my @ary; warn @ary;
>>>
>>> Perl reacts differently to lines 2 and 3 for various reasons, one being
>>> that “my” means different things in the presence of “$” and “@”.
>>
>> It always means the same thing: Create a lexically scoped object of some
>> type.
>
> Right. But
>
> our $sclr; our @ary;
>
> might require “local” in addition to “our”.
I suggest that you stop changing the topic of the conversation with
every sentence as this can only serve to create gratuitious confusion.
By default, using (just like PHP and certain other languages, one I
happen to remember is BASIC) a variable name in Perl for the first time
implictly creates the variable/ object as something whose name can be
resolved by using the symbol table of the current package. While this is
convenient for 'short scripts', it quickly becomes unwieldy in more
complex code. Hence, the compiler can be instructed (typically via 'perl
-Mstrict' or an embedded 'use strict') to reject code referring to
unknown, 'package-global' (technically, that's a misnomer) variables/
objects.
our $scary;
is one way to make the name of such an variable/ object known to the
compiler.
Digressing in yet another direction,
local %kalmar;
creates a new lexically-scoped, dynamic binding for name in symbol table
of the current package.
[...]
> The above might require “= …;”, though. Which is why people are not
> entirely unreasonable if they just put some innocuous assignments
> with “my @ary”, too,
People who mistakenly believe that explicit creation of 'package global'
object was necessary are surely not unreasonably when they - as
mistakenly - conclude that it ought to be necessary for objects with
lexically-scoped names, too. But that the lanuage doesn't provide a way
to do this should eventually cause them to understand that their belief
was mistaken. However, speculations about 'what people might believe'
are besides the point here. Perl provides a short-hand notation for
removing the content of a container object, namely, assign an empty list
to it. If the object is known to be empty, as in
my @leaky_bucked = ();
the assignment is obviously useless to anyone who understands the code
and a gratuitious burden to understanding ("Finally figured it out!
It's useless!") to everybody else. Because of this, it shouldn't exist
to begin with.
[...]
> my ($xyz, ...) = (0, ...);
>
> and subsequent
>
> ++$xyz;
>
> is just more clear
[...]
> than implicit referral to Perl's default way for $xyz to be evaluated
> as 0 of the proper type.
'just more clear' is not a well-defined term. As above, in
my $xyz = 0;
++$xys;
the = 0 is useless.
Adding inherently meaningless statement which - by similarity of form -
suggest that they're as meaningful as the meaningful statements to some
text usually serves to obscure it's actual content, not to clarify it.
------------------------------
Date: Tue, 16 Dec 2014 16:05:48 -0600
From: John Black <jblack@nospam.com>
Subject: Re: Can you point me in the right direction - accessing a website
Message-Id: <MPG.2efa68b7372cdd2598980c@news.eternal-september.org>
In article <MPG.2eeee778967f038698980a@news.eternal-september.org>, jblack@nospam.com says...
>
> In article <Z8ydnQnwQ-vf1B7JnZ2dnUVZ8oGdnZ2d@giganews.com>, news@lawshouse.org says...
> > There's a module called WWW::Mechanize::Firefox which (AIUI) allows you
> > to use FF as the browser engine, but with Perl pulling its strings.
> > I've not tried it, but it might do what you want.
>
> Thanks. This looks like it *could be* EXACTLY what I need. Firefox already knows how to do
> the million things that it needs to do to get into these sites so why would I re-invent the
> wheel. I can just have firefox do it for me and give me the results.
>
> Of course nothing goes smoothly and there is apparently an incompatability with
> WWW::Mechanize::Firefox and cygwin. I think I hacked my way through that but its taken hours
> so I may have to continue this project tomorrow.
>
> But I am hopeful for going this route. Thanks again.
>
> John Black
Just as a followup, I was able to do what I originally wanted using WWW::Mechanize::Firefox.
Thanks for the pointers! It took me a while because using that required that I understand a
little more about web code than I did but I got some further pointers in PerlMonks.
John Black
------------------------------
Date: Tue, 16 Dec 2014 11:16:14 -0800
From: David Harmon <source@netcom.com>
Subject: Re: Help needed on Regular Expressions
Message-Id: <FqidnePyHMLQGA3JnZ2dnUU7-VWdnZ2d@earthlink.com>
On Mon, 1 Dec 2014 21:50:12 -0800 (PST) in comp.lang.perl.misc,
James <hslee911@yahoo.com> wrote,
>($f1, $f2) = @ARGV;
>for (`cat $f2`) {
I like cats, but what is the advantage of invoking the cat there
over just reading the file? Other than breaking on Windows, of
course.
------------------------------
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 4330
***************************************
