[30544] in Perl-Users-Digest
Perl-Users Digest, Issue: 1787 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 11 18:14:24 2008
Date: Mon, 11 Aug 2008 15:14:13 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 11 Aug 2008 Volume: 11 Number: 1787
Today's topics:
Re: empty "if" statement - it doesn't look nice, does i <cwilbur@chromatico.net>
Re: empty "if" statement - it doesn't look nice, does i <RedGrittyBrick@SpamWeary.foo>
Re: empty "if" statement - it doesn't look nice, does i xhoster@gmail.com
Re: empty "if" statement - it doesn't look nice, does i sln@netherlands.com
Re: empty "if" statement - it doesn't look nice, does i sln@netherlands.com
Re: empty "if" statement - it doesn't look nice, does i sln@netherlands.com
Re: FAQ 5.6 How do I make a temporary file name? <tzz@lifelogs.com>
Re: How to check for filetype existence quickly <justin.0805@purestblue.com>
Re: Newbie: Replacing double newlines <tzz@lifelogs.com>
Re: Newbie: Replacing double newlines <ben@morrow.me.uk>
Re: Newbie: Replacing double newlines <tzz@lifelogs.com>
Re: OO Perl <mattj.morrison@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 11 Aug 2008 12:07:15 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: empty "if" statement - it doesn't look nice, does it?
Message-Id: <86ej4vk024.fsf@mithril.chromatico.net>
>>>>> "TC" == Tomasz Chmielewski <tch@nospam.wpkg.org> writes:
TC> I'm saying that I have two conditions ;)
The negation of A && B is !A || !B, or, !(A && B).
The negation of A || B is !A && !B, or, !(A || B).
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 11 Aug 2008 17:25:02 +0100
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: empty "if" statement - it doesn't look nice, does it?
Message-Id: <48a067e1$0$26087$db0fefd9@news.zen.co.uk>
Charlton Wilbur wrote:
>>>>>> "TC" == Tomasz Chmielewski <tch@nospam.wpkg.org> writes:
>
> TC> I'm saying that I have two conditions ;)
>
> The negation of A && B is !A || !B, or, !(A && B).
>
> The negation of A || B is !A && !B, or, !(A || B).
As an addendum:
Peter Makholm mentioned De Morgan's laws.
http://en.wikipedia.org/wiki/DeMorgan%27s_Laws
--
RGB
------------------------------
Date: 11 Aug 2008 16:40:59 GMT
From: xhoster@gmail.com
Subject: Re: empty "if" statement - it doesn't look nice, does it?
Message-Id: <20080811124101.532$mr@newsreader.com>
Tomasz Chmielewski <tch@nospam.wpkg.org> wrote:
> Although an empty "if" statement is technically OK in Perl, it doesn't
> look very nice (and in some languages is even forbidden).
>
> Let's suppose we have a code like:
>
> if ($a == 1 && $b == 2) {
> # Essentially an empty "if" statement
> } else {
> print "We're here only if a is not 1 and b is not 2!\n";
> }
>
> What would be a good way to get rid of this empty "if" statement?
> Or is it OK to have it?
It's OK with me, especially if it only temporarily empty and something
is likely to go there in a future modification of the code. Or even if
it is permanently empty but might contain a useful comment.
if ($aldjflajdsf>98 && $lkjadf<10987) {
## This means the frobnitz isn't compatible with the dohickey
} else {
print "blah blah blah"
}
Although it would usually be better to arrange your variable names and
value such that they are more self-explanatory.
Xho
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Mon, 11 Aug 2008 20:19:13 GMT
From: sln@netherlands.com
Subject: Re: empty "if" statement - it doesn't look nice, does it?
Message-Id: <6p61a4l1f6ke6u2g5kpqvre96cl74hgm6a@4ax.com>
On Mon, 11 Aug 2008 11:36:43 +0200, Tomasz Chmielewski <tch@nospam.wpkg.org> wrote:
>Peter Makholm schrieb:
>> Tomasz Chmielewski <tch@nospam.wpkg.org> writes:
>>
>>> What would be a good way to get rid of this empty "if" statement?
>>
>> Eiter negate the condition or use an "unless" statement instead.
>
>Negating it or using "unless" would yield an unwanted result (but I
>didn't explain it very precisely, sorry for that).
>We want to print the text only if neither $a nor $b were equal a given
>number.
>
>
>Example 1 - does "nothing" (uses empty "if"):
>
>my $a = 1;
>my $b = 2;
>
>if ($a == 1 && $b == 2) {
> # Essentially an empty "if" statement
>} else {
> print "We're here only if a is not 1 and b is not 2!\n";
>}
>
>
>Example 2 - negated, but the result is wrong:
>
>my $a = 0;
>my $b = 2;
>
>if ($a == 1 && $b == 2) {
> # Essentially an empty "if" statement
>} else {
> print "We're here only if a is not 1 and b is not 2!\n";
>}
>
>
>Text was printed, although $b was equal 2. Not what we wanted.
>
>Using "next" or "last" in the empty statement would break the things if
>this "if" was inside of yet another "if".
>"goto" function? Doesn't look much better than an empty "if".
I didn't read the rest of the reply's but I'm sure somebody said this:
> print "We're here only if a is not 1 and b is not 2!\n";
Your here if "a is not 1" OR "b is not 2". Not AND.
Essentially:
if (!($a == 1 && $b == 2))
{
print "We're here only if a is not 1 OR b is not 2!\n";
}
Which, if you "boolean negate" all things in parenthesis (multiply by -1), can be reduced to:
if ($a != 1 || $b != 2)
{
print "We're here only if a is not 1 OR b is not 2!\n";
}
Conclusion, there is no LOGICAL reason to have an empty block just to negate an if statement.
ALL statements can be resolved using BOOLEAN logic, all..
However, as a long time C++ programmer, I can tell you that I do this all the time.
Why?
As a placeholder if the condition were to someday be true.
However the reality is that
this notation: if (!($a == 1 && $b == 2))
is preffered
over this: if ($a != 1 || $b != 2)
because it separates the classes into distinct "what is" and "what isn't",
which is what you wan't.
sln
------------------------------
Date: Mon, 11 Aug 2008 21:03:35 GMT
From: sln@netherlands.com
Subject: Re: empty "if" statement - it doesn't look nice, does it?
Message-Id: <7j81a4t8331qe2afdietud556lca9d63kf@4ax.com>
On Mon, 11 Aug 2008 20:19:13 GMT, sln@netherlands.com wrote:
>On Mon, 11 Aug 2008 11:36:43 +0200, Tomasz Chmielewski <tch@nospam.wpkg.org> wrote:
>
>>Peter Makholm schrieb:
>>> Tomasz Chmielewski <tch@nospam.wpkg.org> writes:
>>>
>>>> What would be a good way to get rid of this empty "if" statement?
>>>
>>> Eiter negate the condition or use an "unless" statement instead.
>>
>>Negating it or using "unless" would yield an unwanted result (but I
>>didn't explain it very precisely, sorry for that).
>>We want to print the text only if neither $a nor $b were equal a given
>>number.
>>
>>
>>Example 1 - does "nothing" (uses empty "if"):
>>
>>my $a = 1;
>>my $b = 2;
>>
>>if ($a == 1 && $b == 2) {
>> # Essentially an empty "if" statement
>>} else {
>> print "We're here only if a is not 1 and b is not 2!\n";
>>}
>>
>>
>>Example 2 - negated, but the result is wrong:
>>
>>my $a = 0;
>>my $b = 2;
>>
>>if ($a == 1 && $b == 2) {
>> # Essentially an empty "if" statement
>>} else {
>> print "We're here only if a is not 1 and b is not 2!\n";
>>}
>>
>>
>>Text was printed, although $b was equal 2. Not what we wanted.
>>
>>Using "next" or "last" in the empty statement would break the things if
>>this "if" was inside of yet another "if".
>>"goto" function? Doesn't look much better than an empty "if".
>
>I didn't read the rest of the reply's but I'm sure somebody said this:
>
>> print "We're here only if a is not 1 and b is not 2!\n";
>
>Your here if "a is not 1" OR "b is not 2". Not AND.
>
>Essentially:
>
>if (!($a == 1 && $b == 2))
>{
> print "We're here only if a is not 1 OR b is not 2!\n";
>}
>
>Which, if you "boolean negate" all things in parenthesis (multiply by -1), can be reduced to:
>
>if ($a != 1 || $b != 2)
>{
> print "We're here only if a is not 1 OR b is not 2!\n";
>}
>
>
>Conclusion, there is no LOGICAL reason to have an empty block just to negate an if statement.
>ALL statements can be resolved using BOOLEAN logic, all..
>
>However, as a long time C++ programmer, I can tell you that I do this all the time.
>Why?
>
>As a placeholder if the condition were to someday be true.
>
>However the reality is that
>
>this notation: if (!($a == 1 && $b == 2))
>is preffered
>over this: if ($a != 1 || $b != 2)
>
>because it separates the classes into distinct "what is" and "what isn't",
>which is what you wan't.
>
>
>sln
>
>
Following up on my own post..
Ok, I just read the other posts.
I am not saying you don't have the 'logic' portion of your brain
when I make this recomendation. Instead, I'm offering a suggestion on how
to develop it.
Its a natural ability to resolve boolean expressions.
Programmers, over time develop this naturally.
Realistaclly, probably %40 of initial codeing errors, and
%20 of remaining errors after fixes, are attributed to errors
in logic, boolean errors.
I call them "conceptual" errors. They are what testers are for.
The people who are very good in boolean logic, can read code
as fast as people read books. They are well paid.
Reading the boolean logic in code is the first line of error detection
when debugging large code. It scrapes off the first layer.
Its re-read for deeper "conceptual" errors, design errors.
By that time, all the flaws are known. The fix is harder.
Well paid people.
If you were good in math since childhood, say intermediate algebra,
could almost do it in your head, you will probably be a good programmer
if you study.
So my suggestion is that if you have access to college, you take a course
called "Formal Symbolic Logic 101". It's all about Boolean symbolism,
sort of Electrical Engineering'ish. In essence, it takes the words, sentences,
paragraphs of .. debate speaches, for instance... or news articles, or whatever..
And formulates BOOLEAN equations to represent them. The equations are then resolved,
ie: reduced, to test the validity of the representation. Its TRUE or FALSE, and why.
Although there are many more constructs of logic in language (human language), that
comprise the conditions, in that context there are many more gradations of fallicy
than can be incorporated into computer language. As such, there are logic laws,
rules, falicy's, that can be easily identified.
The big thing in "Formal Symbolic Logic" is that logic is incorporated to interpret
language. And guess what? The very same formal logic symbolism laws are used in CS and EE and ME
and all the other sciences.
Its an elective in Junior College, take it!
sln
------------------------------
Date: Mon, 11 Aug 2008 21:14:53 GMT
From: sln@netherlands.com
Subject: Re: empty "if" statement - it doesn't look nice, does it?
Message-Id: <0fa1a4he5g3qeimqtu83gvuvmb5hmfrp7g@4ax.com>
On Mon, 11 Aug 2008 21:03:35 GMT, sln@netherlands.com wrote:
>On Mon, 11 Aug 2008 20:19:13 GMT, sln@netherlands.com wrote:
>
<snip>
>Following up on my own post..
>Ok, I just read the other posts.
>
>I am not saying you don't have the 'logic' portion of your brain
>when I make this recomendation. Instead, I'm offering a suggestion on how
>to develop it.
>
>Its a natural ability to resolve boolean expressions.
>Programmers, over time develop this naturally.
>Realistaclly, probably %40 of initial codeing errors, and
>%20 of remaining errors after fixes, are attributed to errors
>in logic, boolean errors.
>
>I call them "conceptual" errors. They are what testers are for.
>
>The people who are very good in boolean logic, can read code
>as fast as people read books. They are well paid.
>
>Reading the boolean logic in code is the first line of error detection
>when debugging large code. It scrapes off the first layer.
>Its re-read for deeper "conceptual" errors, design errors.
>By that time, all the flaws are known. The fix is harder.
>Well paid people.
>
>If you were good in math since childhood, say intermediate algebra,
>could almost do it in your head, you will probably be a good programmer
>if you study.
>
>So my suggestion is that if you have access to college, you take a course
>called "Formal Symbolic Logic 101". It's all about Boolean symbolism,
>sort of Electrical Engineering'ish. In essence, it takes the words, sentences,
>paragraphs of .. debate speaches, for instance... or news articles, or whatever..
>And formulates BOOLEAN equations to represent them. The equations are then resolved,
>ie: reduced, to test the validity of the representation. Its TRUE or FALSE, and why.
>Although there are many more constructs of logic in language (human language), that
>comprise the conditions, in that context there are many more gradations of fallicy
>than can be incorporated into computer language. As such, there are logic laws,
>rules, falicy's, that can be easily identified.
>
>The big thing in "Formal Symbolic Logic" is that logic is incorporated to interpret
>language. And guess what? The very same formal logic symbolism laws are used in CS and EE and ME
>and all the other sciences.
>
>Its an elective in Junior College, take it!
>
>
>sln
>
>
>
Also might help if there are unary expressions like this:
$var &= ~($badval << $bits);
------------------------------
Date: Mon, 11 Aug 2008 10:01:49 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: FAQ 5.6 How do I make a temporary file name?
Message-Id: <86d4kf8ujm.fsf@lifelogs.com>
On Sun, 10 Aug 2008 14:21:25 GMT Michael Carman <mjcarman@mchsi.com> wrote:
MC> PerlFAQ Server wrote:
>> 5.6: How do I make a temporary file name?
>>
>> If you don't need to know the name of the file, you can use "open()"
>> with "undef" in place of the file name.
MC> This should probably contain a caveat that it requires Perl 5.8+
MC> Quite a few of the FAQ entries implicitly assume that they're being read
MC> locally and thus have the necessary version of perl available. Between
MC> postings here and online versions this isn't a safe assumption.
If something's posted, it should be the FAQ pertaining to the latest
Perl, don't you think?
I'd add a 'use 5.8...' line to the FAQ answer in such cases, it's a lot
more concise than writing out "it requires 5.8" and the code will fail
in a more obvious way (even if the FAQ reader doesn't bother to read the
whole entry).
Ted
------------------------------
Date: Mon, 11 Aug 2008 14:11:28 -0000
From: Justin C <justin.0805@purestblue.com>
Subject: Re: How to check for filetype existence quickly
Message-Id: <2d82.48a04890.19a6d@zem>
On 2008-08-07, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2008-08-06 10:18, Justin C <justin.0805@purestblue.com> wrote:
>> On 2008-08-06, fidokomik <fidokomik@gmail.com> wrote:
>>> I have directory, say "c:\documents" on Windows or "/home/petr/
>>> documents" on Linux. In this directory many files are stored with many
>>> filetypes (extensions), say *.doc, *.txt, *.zip. I need to find fastes
>>> way how to check if some filetype exist. Now I use routine where I use
>>> readdir() and return true if passed filetype is first time found but
>>> when I have huge number of files but passed filetype is not found then
>>> routine is very slow before return false.
>>> Any idea?
>>
>> ls | egrep doc\|txt\|zip
>
> Please not that the OP is passed *one* filetype. So that would be
>
Well spotted. Thanks for pointing it out.
[snip]
>> I know you want to use perl, but perl won't be as fast as this... unless
>> there are a very, very large[1] number of files.
>
> Perl is also likely to be faster for a small number of files - spawning
> a shell which then spawns two other programs is not exactly a cheap
> operation.
Gasp! You mean, you don't *always* have a TERM to hand?! :) I see
what you mean, I was just thinking quick and dirty, and not "write once,
use many"... which is a habit I'm trying to cultivate.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Mon, 11 Aug 2008 09:58:51 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Newbie: Replacing double newlines
Message-Id: <86hc9r8uok.fsf@lifelogs.com>
On Sat, 09 Aug 2008 13:01:36 +0200 magloca <magloca@mailinater.com> wrote:
m> Ben Morrow wrote:
>> -0777 is equivalent to BEGIN { $/ = undef }: see perlrun.
m> Wow, that's obscure even for Perl. :D
You don't want to know what -0666 does (one side effect is, the hex()
function is redefined to do something entirely different).
Ted
------------------------------
Date: Mon, 11 Aug 2008 17:19:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Newbie: Replacing double newlines
Message-Id: <ad56n5-ep3.ln1@osiris.mauzo.dyndns.org>
Quoth Ted Zlatanov <tzz@lifelogs.com>:
> On Sat, 09 Aug 2008 13:01:36 +0200 magloca <magloca@mailinater.com> wrote:
>
> m> Ben Morrow wrote:
> >> -0777 is equivalent to BEGIN { $/ = undef }: see perlrun.
>
> m> Wow, that's obscure even for Perl. :D
>
> You don't want to know what -0666 does (one side effect is, the hex()
> function is redefined to do something entirely different).
I think this post was missing a smiley :).
Ben
--
I touch the fire and it freezes me, [ben@morrow.me.uk]
I look into it and it's black.
Why can't I feel? My skin should crack and peel---
I want the fire back... BtVS, 'Once More With Feeling'
------------------------------
Date: Mon, 11 Aug 2008 11:39:23 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Newbie: Replacing double newlines
Message-Id: <86ljz37bgk.fsf@lifelogs.com>
On Mon, 11 Aug 2008 17:19:22 +0100 Ben Morrow <ben@morrow.me.uk> wrote:
BM> Quoth Ted Zlatanov <tzz@lifelogs.com>:
>> On Sat, 09 Aug 2008 13:01:36 +0200 magloca <magloca@mailinater.com> wrote:
>>
m> Ben Morrow wrote:
>> >> -0777 is equivalent to BEGIN { $/ = undef }: see perlrun.
>>
m> Wow, that's obscure even for Perl. :D
>>
>> You don't want to know what -0666 does (one side effect is, the hex()
>> function is redefined to do something entirely different).
BM> I think this post was missing a smiley :).
}:)
Ted
------------------------------
Date: Mon, 11 Aug 2008 12:37:04 -0700 (PDT)
From: Matt <mattj.morrison@gmail.com>
Subject: Re: OO Perl
Message-Id: <f7833e96-648d-465a-b041-a8c23fff8f0a@f36g2000hsa.googlegroups.com>
> That advantage vanishes if you have several projects on several
> servers using several of your modules. Now you need to keep track of
> which modules you need to deploy on which server, exactly as if you used
> modules from CPAN. And unlike CPAN, your system for deployment probably
> doesn't keep track of dependencies.
I don't quite follow. If you have multiple projects on multiple
servers and a module that you're using changes, regardless of if
you're using a CPAN module or not you'll still have to update ever
server for every project. The thing about my OO Module is that there
are NO dependencies...the only thing you need is a clean Perl (5.8.8)
installation. In my mind I'm trying to compare this to a Java
Enterprise Archive. You've got an EAR file that contains a bunch of
Java Archive files...if you need a new version of a JAR file, you
download it, and replace that in your ear...it only impacts that one
application and you don't have to worry about regression testing every
single application on that server...when you install a Perl module you
could potentially impact anything on that server unless you install it
to a specific directory (right?). What happens if you've got 200
projects on a server that are all unrelated. If you have a module
that you want to install but you don't want to have to regression test
all other 199 projects you install it to a specific directory, or
something, right? What if 50 projects need that module? Do you have
to install that module 50 times to those specific directories? Do you
have to reorganize the entire directory structure so that you can
install a Perl module for a group of projects? How do you manage a
group of 50 that need 1 module and a group of 100 that need a
different module...what happens if there is overlap? Sorry for the
novel. If somebody can clarify how this would work using CPAN Modules
installed the "standard" way, I'd really appreciate it.
Thanks!
------------------------------
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 1787
***************************************
