Question for the regulars

[A. Sinan Unur]

One habit I've gotten into over the years - when I'm comparing against
a literal, I put the literal on the left, like this:

if (5 == $foo)

But then, it doesn't look as natural as it would otherwise.

That way, if I typo a '=' where the '==' belongs, I *do* get an error.

use warnings;

should help with that

D:\Home\asu1\UseNet\clpmisc> cat sss.pl
#!/usr/bin/perl

use strict;
use warnings;

my $x = 1;
if ( $x = 5 ) {
print "Yes\n";
} else {
print "No\n";
}
__END__

D:\Home\asu1\UseNet\clpmisc> sss
Found = in conditional, should be == at
D:\Home\asu1\UseNet\clpmisc\sss.pl line 7. Yes

 

[Joe Smith]

I have demonstrated, factually, dozens of times Stein's module
is the number one worst written module.

Your arguments are not convincing.
They are not facts.

 

[ced]

If "worst" is defined as stupid and senseless, I sometimes return to my
roots programming in more primative languages and make this sort of
mistake:

if ($foo = $bar) {

when I really wanted to use "==" or "eq". It's perfectly valid code
(ie, it won't throw an error or a warning). I have stared at buggy code
for longer than I care to admit and have missed this mistake.

Hm, if you really want to confuse and corrupt the youth of today,
have them learn shell programming. '=' can be a valid comparator
there.

 

[Dr.Ruud]

A. Sinan Unur:

Sherm Pendley:

But then, it doesn't look as natural as it would otherwise.

Why not? I have been using and promoting and teaching it for over 20
years and it looked perfectly natural from the start to me, in C and in
any other language having operators like ==, !=, ===, !==, etc.


Does perl6 support the following?

if ('bert'|'ernie' eq $char)

 

[A. Sinan Unur]

A. Sinan Unur:

Why not?

Because "if $foo is equal to five" sounds more natural to me both in
Turkish and English than "if 5 is equal to $foo".

I have decided this one of those style issues that does not offer a huge
benefit, especially coupled with the fact that if you do commit the
error of writing if ($foo = 5), you will get a warning from any self-
respecting compiler with the appropriate warnings set.

Sinan

 

[Dr.Ruud]

A. Sinan Unur:

"if $foo is equal to five" sounds more natural to me both in
Turkish and English than "if 5 is equal to $foo".

First you were talking looks, now sounds.
Well, just read "==" as "is the value of" or something alike.

Equality can have order though, when '==' is overloaded.

 

[A. Sinan Unur]

A. Sinan Unur:


First you were talking looks, now sounds.

How a piece of code is perceived is based on how it reads.

Well, just read "==" as "is the value of" or something alike.

I don't see the point going through contortions like this to justify a
style choice.

if ($x == 5)

is most naturally read as "if $x is equal to 5".

Equality can have order though, when '==' is overloaded.

In most cases, it would be an abuse of overloading if

$x == $y

and

$y == $x

gave different results.

Maybe you can give an example where that makes sense.

Sinan

 

[Dr.Ruud]

A. Sinan Unur:

Dr.Ruud:

How a piece of code is perceived is based on how it reads.


I don't see the point going through contortions like this to justify a
style choice.
if ($x == 5)
is most naturally read as "if $x is equal to 5".


In most cases, it would be an abuse of overloading if
$x == $y
and
$y == $x
gave different results.

Maybe you can give an example where that makes sense.

Thanks, you now presented that '==' shouldn't have order, so ($x == 5)
shouldn't be more <insert any quality> than (5 == $x).
(And of course I apologize for setting you up like this.)

To me, the format (5 == $x) is not a style choice. I consider code with
(<constant> == <variable>) of higher quality. Or in possibly 'more
natural' terms: I like its artficiality, and how it promotes the concept
of equality.

 

[A. Sinan Unur]

A. Sinan Unur:

Thanks, you now presented that '==' shouldn't have order, so ($x == 5)
shouldn't be more <insert any quality> than (5 == $x).

Well, you are comparing apples and oranges. Logical equivalence versus
clarity of expression in this case.

If the question you are asking is "is $x equal to 5?" then it is a
contortion to write "is 5 the value of $x?" We don't talk like that, why
program like that?

(And of course I apologize for setting you up like this.)

If you have a point, it is lost on me.

To me, the format (5 == $x) is not a style choice. I consider code
with (<constant> == <variable>) of higher quality.

As I mentioned, that's a personal preference. I agree with irony
expressed in the last statement of:

Or in possibly 'more natural' terms: I like its artficiality,
and how it promotes the concept of equality.

Whatever perceived advantage (<constant> == <variable>) has, disappears
the moment you are comparing $x to $y. Hence, my mental energy is better
spent remembering to use == rather than trying to reverse the operands.
(Especially since the warning you receive from the compiler will be the
same in either case).

This is becoming fairly tedious, and I have no desire to continue this
subthread that has lived far too long.

Sinan

 

[A. Sinan Unur]

Whatever perceived advantage (<constant> == <variable>) has,
disappears the moment you are comparing $x to $y. Hence, my mental
energy is better spent remembering to use == rather than trying to
reverse the operands. (Especially since the warning you receive from
the compiler will be the same in either case).

This is becoming fairly tedious, and I have no desire to continue this
subthread that has lived far too long.

Oops, I spoke too soon! Apparently, you get no warning when you write
if ($x = $y):

#!/usr/bin/perl

use strict;
use warnings;

my ($x, $y) = (1, 5);

if ( $x = $y ) {
print "Yes\n";
} else {
print "No\n";
}
__END__

This will print Yes with no warnings issued.

Whereas, with

#include <stdio.h>

int main(void) {
int x = 1;
int y = 5;
if( x = y ) {
puts("Yes");
} else {
puts("No");
}
return 0;
}

I get

D:\Home\asu1\UseNet\clpmisc> gcc -Wall -c s.c
s.c: In function `main':
s.c:6: warning: suggest parentheses around assignment used as truth
value

or

D:\Home\asu1\UseNet\clpmisc> cl /Wall s.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for
80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights
reserved.

s.c
d:\home\asu1\usenet\clpmisc\s.c(6) : warning C4706: assignment within
conditional expression

This behavior I was used to from the C compilers I have used was the
basis for my statement.

However, the fact that no warnings are issued when the equivalent Perl
code is compiled supports the argument that it pays off more to get in
the habit of remembering to type == even more.

I am going to shut up now.

Sinan

 

[John Bokma]

A. Sinan Unur:

Why not?

Because it promotes defensive programming.

I have been using and promoting and teaching it for over 20
years and it looked perfectly natural from the start to me, in C

I haven't seen a C compiler that did not warn on:

if ( x = 4 ) {

}

Of course there are people who prefer to turn warnings off as much as
possible.

 

[John Bokma]

As a reader, my thought is that there are a lot of assholes on this
group who enjoy posting smug and superior replies to legitimate
questions kindly asked or to positions such as yours that differ from
whatever the perldoc recommends. And I'm right.


I know I would appreciate hearing some facts to support his position,
rather than an automaton-like citation of the Perl faq, but I don't
think we're going to get any.

Aarg, it's making friends :-(

 

[Sherm Pendley]

But then, it doesn't look as natural as it would otherwise.

It doesn't bother me, but that's subjective. YMMV.

use warnings;

should help with that

Only when I'm writing Perl... ;-)

sherm--

 

[Bart Lateur]

You have only factually demonstrated over the years that you know very
little about Perl, and less about the cgi environment. Please show us how
your code is better. Many in a technical group expect statements to enjoy a
factual basis, you know. You vague claims have no factual basis.

I agree with PurlGurl on this one: CGI.pm *is* an ugly module: it's
huge, making it less fit for what its original intention is, namely for
use in CGI scripts. It's bulky, containing lots of stuff most people
don't use, like the HTML generating stuff. It's ugly, like in how each
function is held in the module as a string, which gets evalled the
function is called, and it uses an unreliable way to test whether a sub
is called as a method or as a function (I've demonstrated in the past
how certain parameter values in a function call can make it fail -- try
strings like "CGI"). The proper way for the latter would have been to
have separate subs for the methods and for the functions, say, in a
separate original package, where the function adds a default parameter
to call the method.

This module is butt ugly, and should have been abandoned/refactored
years ago. Yet people defend it like it's the greatest module ever
written. Though it's not the absolute worst, it clearly isn't.

And yes, I do know of PurlGurl's reputation. I'm not on her side most of
the time.

 

[Dr.Ruud]

A. Sinan Unur:

Logical equivalence versus clarity of expression in this case.

Because ($x == 42) isn't any clearer than (42 == $x) but some 'believe'
or 'feel' that it is, those should all start coding like (42 == $x) too,
and 'hope' that they will get rid of that notion.

If the question you are asking is "is $x equal to 5?" then it is a
contortion to write "is 5 the value of $x?" We don't talk like that,
why program like that?

You are looking for meaning where there is none.

As I mentioned, that's a personal preference.

And as I mentioned, it is a tool.

I agree with irony
expressed in the last statement of:

<URL: http://www.eskimo.com/~scs/C-faq/q17.4.html>

Then something got lost on you again. Somebody who uses "evidently it
can" and "reverse the test" there, evidently has a reasoning problem.

Whatever perceived advantage (<constant> == <variable>) has,
disappears the moment you are comparing $x to $y.

This is becoming fairly tedious, and I have no desire to continue this
subthread that has lived far too long.

The second format is also good counter-religion:

for (my $i = 0; $i < 10; $i ++)

for (my $i = 0; 10 != $i; ++ $i)

 

[Dr.Ruud]

John Bokma:

Dr.Ruud:

Because it promotes defensive programming.

Drinking water promotes drowning? Yes, it can be part of a defensive
programming style too, and some kinds of defensive programming (in the
limited sense as I guess you define it) do real damage, but 'looking
natural' and Huffman don't have a high correlation.

I haven't seen a C compiler that did not warn on:

if ( x = 4 ) {

}

I have seen them. Maybe it was even the main reason why lint was
created. That was long ago and is not the issue.

Of course there are people who prefer to turn warnings off as much as
possible.

I already explained why I still promote <constant> == <variable>, and
that doesn't have anything to do with compiler warnings or alike, so
reset and try again.

 

[Eric Bohlman]

In most cases that I have seen here, NOT using CGI.pm is a mistake often
made.

I'd put in parentheses "or another properly-tested CGI decoding module".

What you're describing is actually a sub-case of a more general
"antipattern": writing code which makes best-case assumptions about data
coming from an outside source. Trying to parse HTML with regexes is
another example. The problem with half-assed decoding/parsing code is that
it so often gives the right results that the times it doesn't are easy to
overlook. People often think that they can code a "better" or "more
efficient" version themselves but they forget that for such tasks, most of
the effort to do it right goes into writing tests rather than coding.
You're better off if someone has already done that work for you.

 

[A. Sinan Unur]

I agree with PurlGurl on this one: CGI.pm *is* an ugly module: it's
huge, making it less fit for what its original intention is, namely
for use in CGI scripts.
....

This module is butt ugly, and should have been abandoned/refactored
years ago. Yet people defend it like it's the greatest module ever
written. Though it's not the absolute worst, it clearly isn't.

The question that still remains is: Is it a worse mistake to use CGI.pm
than not to use it?

And, if one chooses not use use it, is it a worse mistake to use one's
own hand-rolled solution than an alternative module from CPAN.

I mentioned

perldoc -q "How do I decode a CGI form?"

because it refers to CGI::Minimal as an alternative.

Sinan

 

[A. Sinan Unur]

I'd put in parentheses "or another properly-tested CGI decoding
module".

I agree fully with your explanation (which I snipped for brevity).

I mentioned the FAQ "for more information" because it points to valid
alternatives to CGI.pm. I just did not want to get into an extended debate
with PG.

Sinan

 

[A. Sinan Unur]

So, if CGI.pm isn't a good idea, what would you suggest is a better
alternative?

Did you actually read

perldoc -q "How do I decode a CGI form?"

I personally like the look of Templates, i.e. Template-Toolkit.

This is why you are not even remotely close to being in a position
to be able to form an informed judgement. What does TT, a module
which I use both for work and pleasure, have to do with CGI processing?

Do you have any views on this that you could enlighten me with?

Oh, it certainly has views:

<URL: http://groups.google.com/groups?as_q=godzilla+cgias_ugroup=comp.lang.perl.misc>

<URL: http://groups.google.com/group/comp..._frm/thread/42fe757abc6b8e8a/817d160d4c06c20c>

Sinan