[12611] in Perl-Users-Digest
Perl-Users Digest, Issue: 20 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 6 18:17:12 1999
Date: Tue, 6 Jul 1999 15:06:26 -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 Tue, 6 Jul 1999 Volume: 9 Number: 20
Today's topics:
Re: 2 simple (not to me tho) questions (Tad McClellan)
Re: 2 simple (not to me tho) questions (Steve Lamb)
Re: 2 simple (not to me tho) questions (Steve Lamb)
Re: 2 simple (not to me tho) questions <mike@crusaders.no>
Re: 2 simple (not to me tho) questions <uri@sysarch.com>
Re: 2 simple (not to me tho) questions (Steve Lamb)
Re: 2 simple (not to me tho) questions (Steve Lamb)
Re: 2 simple (not to me tho) questions (I R A Aggie)
Re: 2 simple (not to me tho) questions (Ronald J Kimball)
Re: 2 simple (not to me tho) questions (Tony Kennick)
Re: 2 simple (not to me tho) questions (Bart Lateur)
Re: 2 simple (not to me tho) questions <uri@sysarch.com>
Re: 2 simple (not to me tho) questions (Abigail)
Re: 2 simple (not to me tho) questions (Abigail)
Re: 2 simple (not to me tho) questions <palincss@his.com>
Re: 2 simple (not to me tho) questions (James W. Sandoz)
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 2 Jul 1999 17:59:30 -0400
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <2ocjl7.iu3.ln@magna.metronet.com>
Steve Lamb (morpheus@despair.rpglink.com) wrote:
: On Thu, 1 Jul 1999 20:59:59 -0400, Tad McClellan <tadmc@metronet.com> wrote:
: >: It is also a consistancy issue.
: > You can consistently not use double quotes too, so I'm not
: > following you on that part...
: I never knew that. Lemme try...
Well let me state it more clearly for the disingenuously inclined.
You can consistently not use double quotes around nothing but
a variable name.
In case that too is unclear, let me say it yet another way.
You can consistently use
print $var;
as well as
print "$var";
when you want to print only the value of a variable.
Using some_func("$var") for one function where you have said
that you use some_func($var) for every other function is
INconsistent, not consistent.
So I still don't know what "consistancy issue" you are
referring to...
: That is why I wrote a message with four print statements, the only
: difference was the inclusion of \n. In one set the non \n string didn't have
: quotes, in the other it did. In the end the output was the same. However,
: the code was more consistant, stylistically.
And harder to read.
: In short, it looks like people here, generally, quote only when needed to
: save on CPU cycles,
I don't know about those people. I am not one of those.
I generally only quote when quoting is _needed_, because it
is not nice to provide false cues.
: to get the warm fuzzies of shaving a few characters off
: their code, whatever.
I want to save brain cycles, not CPU cycles.
: I am the opposite, I generally quote unless it harms
: something
It harms communication of your intent to the maintainer of
your code.
: to keep the code stylistically consistant and readable.
: TMTOWTDI, except, of course, to a select few people who want to argue the
: point by pointing out that, even though they admit they would put the variable
: in double-quotes if they needed to append an \n to the string
Because the double quotes will cue the maintainer that _more_
than just the value of a variable is being printed.
: > Well I don't know about them. You would have to take that up
: > with a Perl hacker.
: Well, considering Tom Christiansen decided to be a prick about it, you
: tell me. *shrug*
My name is Tad McClellan.
If you have a beef with me, then speak to me in a followup to me.
If you have a beef with Tom Christiansen, then attach it to a
followup to Tom Christiansen's post.
: Style, all style.
Ease of maintenance, all ease of maintenance.
Tastes great!
Less filling!
Tastes great!
...
: I'm not into the reduce the code to the least amount of
: characters to show my studly perl prowess.
Me either.
I'm also not into providing red herrings for those that follow
me to chase.
: >: So far, no one has come up with anything against print("$var")
: > It is a code maintenance issue.
:
: > print $var or print($var) is more easily maintained than
: > print "$var" or print("$var").
: Which is 100% bogus because, in the course of the thread, it has been
: stated by at least one person who is on the print($var) bandwagon that he
: would print("$var\n") instead of print($var."\n")
Because the double quotes will cue the maintainer that _more_
than just the value of a variable is being printed.
: even though the latter is
: clearly more maintainable.
It is not clear to me.
I think that "$var\n" is more maintainable than $var."\n"
Care to give any reasons why you think the second method
is preferable from a maintenance point of view?
: In fact, when someone pointed that out, the person
: replied they would "always" do that.
He probably doesn't like spending more money (time) than is
needed to get the (maintenance) job done.
: If code maintainability were the only issue, we would see people
: denouncing:
: print("The $rain in $spain stays $mainly in the $plain\n");
: for:
: print("The ".$rain." in ".$spain." stays ".$mainly." in the ".$plain."\n");
I think that "$var\n" is more maintainable than $var."\n"
Care to give any reasons why you think the second method
is preferable from a maintenance point of view?
: > No time wasted examining code that cannot be causing, for instance,
: > extra newlines to be showing up.
: Then, as I stated, one would then use print($var."\n") if they really
: believed that.
Nonsense.
When reading
"$var\n"
I know at the first character that something more than just
the value of the variable is being used
$var."\n"
takes *more* time to understand, not less time.
Less time is good for maintenance.
--
Tad McClellan SGML Consulting
tadmc@metronet.com Perl programming
Fort Worth, Texas
------------------------------
Date: 3 Jul 1999 12:26:14 GMT
From: morpheus@despair.rpglink.com (Steve Lamb)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <slrn7ns0b5.1bc.morpheus@rpglink.com>
On Fri, 2 Jul 1999 17:59:30 -0400, Tad McClellan <tadmc@metronet.com> wrote:
> Using some_func("$var") for one function where you have said
> that you use some_func($var) for every other function is
> INconsistent, not consistent.
Because I would use print("") damn near everywhere else. The various
print statements used quotes (single & double) more often than not.
> So I still don't know what "consistancy issue" you are
> referring to...
Well, there it is.
> And harder to read.
That is a matter of opinion. That is why I have the assertation that it
is a *STYLISTIC* issue.
> I generally only quote when quoting is _needed_, because it
> is not nice to provide false cues.
Then you use ptiny($var."\n"), right?
> It harms communication of your intent to the maintainer of
> your code.
That is a hoot when you're talking about perl. Personally I cannot stand:
next if (some condition);
Yet people use it all the time and it is legal. I can't stand:
if (some condition)
{
next;
}
Yet it is legal. Or even:
if (some condition) { next; }
Yet it is legal. All of those are more distracting than print($foo)
versus print("$foo").
> Because the double quotes will cue the maintainer that _more_
> than just the value of a variable is being printed.
Aaaand, so what? I doubt many people really look at it that way.
> I think that "$var\n" is more maintainable than $var."\n"
>
> Care to give any reasons why you think the second method
> is preferable from a maintenance point of view?
Because it is clear, then, what is being added and what is not. If
clarity of maintenence with your absurd viewpoint on it is all that matters,
that is.
> $var."\n"
> takes *more* time to understand, not less time.
> Less time is good for maintenance.
Mmm, really. "Oh, the \n is being added." Wow, that was hard. Where the
former example "$var\n" is more of a "Something is being, added, oh, \n". Or,
to make a more radical example....
print("$foo$bar$fim$fart\n$foo$bim$fart$front\n");
print($foo.$bar.$fim.$fart."\n".$foo.$bim.$fart.$front."\n");
If code maintainability was all you wanted, the 2nd would be preferable
since, clearly, what is being added stands out because of the double quotes.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
------------------------------
Date: 3 Jul 1999 12:32:16 GMT
From: morpheus@despair.rpglink.com (Steve Lamb)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <slrn7ns0mg.1bc.morpheus@rpglink.com>
On 02 Jul 1999 12:30:18 -0600, Daniel Grisinger
<dgris@moiraine.dimensional.com> wrote:
>Did you think that you were such a better programmer than the average
>participant here that we'd all bow down to your superior knowledge?
No, I expected people to actually be open to people who code differently
than they do over stylistic issues.
>I'll say it one more time-- there is always more than one way to do
>something. Most of those ways suck. We know the difference between
>the good ways and the bad ways. Ignore us at your own risk.
You know, if people could come up with *ONE* good reason, other than
stylistic, on why print("$var") is, in and of itself, inherently bad,
absolutely, 100% of the time over print($var) when the $var in question is
perfectly acceptable in print("$var\n") I might just tend to agree that I am
doing something that may introduce bugs and, as you say, introduce "risk."
However, not one person has shown any problems with it. In fact, in the
course of the discussion all they have shown is their own hypocricy. IE,
print($var), print("$var\n") but not print($var."\n").
All of this because I choose to place double-quotes around my print
statements unless there is a compelling reason not to (print(@foo) for
example) and one individual decided to ignore me saying that and take it to
the scope of ALL functions which, in case people have missed it (which they
did) I agree is a bad thing. Jeez.
So, where is the risk. I am now waiting for you to tell me a case where
$var must be print($var) or be harmed when it is perfectly legal in
print("$var\n").
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
------------------------------
Date: Sat, 3 Jul 1999 16:28:57 +0200
From: "Trond Michelsen" <mike@crusaders.no>
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <U7pf3.238$nk6.909@news1.online.no>
Steve Lamb <morpheus@despair.rpglink.com> wrote in message
news:slrn7ns0b5.1bc.morpheus@rpglink.com...
> > It harms communication of your intent to the maintainer of
> > your code.
> That is a hoot when you're talking about perl. Personally I cannot
stand:
> next if (some condition);
> Yet people use it all the time and it is legal. I can't stand:
> if (some condition)
> {
> next;
> }
> Yet it is legal. Or even:
> if (some condition) { next; }
The last two examples look alike to me, but just out of couriosity; what
would be the 'correct' usage of this kind of statement.
Is
(some condition) && next;
better or worse?
I personally lean towards "next if (some condition);" and "next unless (some
condition);"
--
Trond Michelsen
------------------------------
Date: 03 Jul 1999 10:46:41 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <x7zp1dzt7y.fsf@home.sysarch.com>
>>>>> "SL" == Steve Lamb <morpheus@despair.rpglink.com> writes:
SL> No, I expected people to actually be open to people who code
SL> differently than they do over stylistic issues.
ok, let me make this clear. this is not a style issue, but a semantic
one. do you knwo the difference between those two terms? indenting,
names, whitespace are all style issues. using a foreach loop vs. a
foreach modifier is style. using || or unless is style.
print "$var" is a semantic issue. tad has explained it several times to
you. it TELLS the human reader that there is some interpolation going on
here other than the single var. it matters not that print will stringify
the var anyway. so it is MISLEADING to the next person who reads the
code. is is a MISGUIDED attempt by you to assert a style when you are
really showing little respect for your code.
SL> You know, if people could come up with *ONE* good reason,
SL> other than stylistic, on why print("$var") is, in and of itself,
SL> inherently bad, absolutely, 100% of the time over print($var) when
SL> the $var in question is perfectly acceptable in print("$var\n") I
SL> might just tend to agree that I am doing something that may
SL> introduce bugs and, as you say, introduce "risk." However, not
SL> one person has shown any problems with it. In fact, in the course
SL> of the discussion all they have shown is their own hypocricy. IE,
SL> print($var), print("$var\n") but not print($var."\n").
i just gave a reason as did tad and others. you don't want to get it. it
is not a STYLE issue but a SEMANTIC one. code is for humans and not for
computers. the maintainer of your code will curse you out (more than you
have seen here) for putting quotes where it is NOT NEEDED and making
him wonder why they were put there. you are being very self serving
becuase you think it is a cool style while it is not an accepted
practice. the fact that perl allows it and TIMTOWTDI is
irrelevent. there are so many bad ways of doing things in perl, why
don't you try them all. it will make you have an even more personal and
consistant 'STYLE'.
SL> All of this because I choose to place double-quotes around my
SL> print statements unless there is a compelling reason not to
SL> (print(@foo) for example) and one individual decided to ignore me
SL> saying that and take it to the scope of ALL functions which, in
SL> case people have missed it (which they did) I agree is a bad
SL> thing. Jeez.
because that is inconsistant. why do you single out print to have quotes
on naked vars while other functions don't? that is the inconsistancy
that we are telling you about. by showing how wrong it is for other
functions we hoped and prayed that your peabrain will see the bigger
picture. but you are stuck in a broken record about "it is my STYLE"
which is wrong.
SL> So, where is the risk. I am now waiting for you to tell me a
SL> case where $var must be print($var) or be harmed when it is
SL> perfectly legal in print("$var\n").
it is NOT A LEGALITY issue. do you get it? no one said it is illegal to
do anything syntactically correct in perl. it is WRONG to do it for code
maintenace reasons. have you ever tried to maintian someone else's code
which you have never seen before? and you couldn't figure out what they
were doing because they didn't follow industry conventions? i bet you
haven't. there are reason you don't do legal things in any
language. ever heard of spaghetti code or lots of single char var names
or any other stupid coding practice? in perl, quoting naked vars is such
a stupid practice no matter what function you are calling.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.
------------------------------
Date: 3 Jul 1999 15:10:17 GMT
From: morpheus@despair.rpglink.com (Steve Lamb)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <slrn7ns9uo.bg4.morpheus@rpglink.com>
On Sat, 3 Jul 1999 16:28:57 +0200, Trond Michelsen <mike@crusaders.no> wrote:
>I personally lean towards "next if (some condition);" and "next unless (some
>condition);"
To me this isn't good. That is because you're stating what you're doing
before the check. For me, when I read code, having the if/unless first is
good because it gives me something to check on before reading the rest of
the code. If I know the if/unless is true/false, I can skip the ensuing block
of code.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
------------------------------
Date: 3 Jul 1999 15:25:41 GMT
From: morpheus@despair.rpglink.com (Steve Lamb)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <slrn7nsari.bg4.morpheus@rpglink.com>
On 03 Jul 1999 10:46:41 -0400, Uri Guttman <uri@sysarch.com> wrote:
>ok, let me make this clear. this is not a style issue, but a semantic
>one. do you knwo the difference between those two terms?
Yes, I do.
>indenting, names, whitespace are all style issues. using a foreach loop vs. a
>foreach modifier is style. using || or unless is style.
Doublequotes on print is a style issue as well.
>it TELLS the human reader that there is some interpolation going on here
>other than the single var.
If that were the case, people would be advocating print($var,"\n") to TELL
the human reader WHERE, exactly, that is happening. Since you, nor anyone
else, is advocating that, it is style. *plonk*
>i just gave a reason as did tad and others. you don't want to get it.
No, I'm pointing out that the reasons you're giving are complete and
utter bullshit because you don't take it to the logical conclusion as I have
pointed out about a dozen times now. It is like the religious right who quote
the story of Lot/Sodam as being agaist homosexuality and blatently ignore the
fact that Lot offered up his daughters as cheap whores. You are saying, "Do
it this way, because I say so because of this reason" yet when I take that
same reason (story) and point out that if you truely believed it you would do
it another way (offer up your daughters as whores) you conveniently ignore
that point and reiterate, "Do it this way, because I say so."
>it is not a STYLE issue but a SEMANTIC one.
Until you, and everyone else, starts advocating print($var."\n"), it is
most certainly style.
>code is for humans and not for computers. the maintainer of your code will
>curse you out (more than you have seen here) for putting quotes where it is
>NOT NEEDED and making him wonder why they were put there.
Oh, you mean like print("$var\n") when the variable doesn't need to be in
the quotes?
>you are being very self serving becuase you think it is a cool style while it
>is not an accepted practice.
No, I am pointing out that advocating print($var) and stating
print("$var\n") is acceptable instead of advocating print($var."\n") is
hypocritical. I don't like hypocrits, esp. when it comes to snotty brats like
you and Tom.
>because that is inconsistant. why do you single out print to have quotes
>on naked vars while other functions don't?
Because print is, in my mind, like the verb "to say".
He said, "I wonder what she had for lunch."
She said, "A pizza, you dolt!"
print("I wonder what she had for lunch.");
print("A pizza, you dolt!");
>that is the inconsistancy that we are telling you about. by showing how wrong
>it is for other functions we hoped and prayed that your peabrain will see the
>bigger picture. but you are stuck in a broken record about "it is my STYLE"
>which is wrong.
Yet there is an inconsistancy in that print is also one of the very few
functions which, in more cases than not, it will have strings quoted in one
fastion or another yet you chose not to have it quoted just because it is a
single var. I am well aware of the "inconsistancy" when compared to other
functions. But each function is different, isn't it?
>it is NOT A LEGALITY issue. do you get it? no one said it is illegal to
>do anything syntactically correct in perl.
I beg to differ. Wasn't it Tom who said it was dangerous and wrong? :P
>maintenace reasons. have you ever tried to maintian someone else's code
>which you have never seen before? and you couldn't figure out what they
>were doing because they didn't follow industry conventions?
Actually, yes, I have, happens all the forking time in my job. Perl, of
course, makes it worse because there are several ways to do things, which I
have pointed out.
>i bet you haven't. there are reason you don't do legal things in any
>language. ever heard of spaghetti code or lots of single char var names
>or any other stupid coding practice? in perl, quoting naked vars is such
>a stupid practice no matter what function you are calling.
It is a stupid practice because of what? You still have not explained it
because you insist, apparently, that print("$var\n") is acceptable when,
clearly, by your OWN ARGUEMENT print($var,"\n") is the "correct" way to do it.
Hypocrits, when they have their hypocricy pointed out to them, have no
arguement left. Good bye. You bore me.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
------------------------------
Date: 3 Jul 1999 15:32:47 GMT
From: fl_aggie@thepentagon.com (I R A Aggie)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <slrn7nsbdc.aff.fl_aggie@thepentagon.com>
On 2 Jul 1999 18:55:27 -0500, Abigail <abigail@delanet.com>, in
<slrn7nqkan.31h.abigail@alexandra.delanet.com> wrote:
+ *sigh* If only those programmers would share something useful. Like
+ which colour nail polish to use with the green dress.
Purple, of course.
Oh, you wanted something *you'd* like? Sheesh... ;)
James
I can please only one person per day. Today is not your day. Tomorrow
isn't looking good, either.
-- Dogbert
------------------------------
Date: Sat, 3 Jul 1999 12:31:00 -0400
From: rjk@linguist.dartmouth.edu (Ronald J Kimball)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <1dud7lx.1ll3247hqjbggN@p86.tc1.metro.ma.tiac.com>
Steve Lamb <morpheus@despair.rpglink.com> wrote:
> So, where is the risk. I am now waiting for you to tell me a case where
> $var must be print($var) or be harmed when it is perfectly legal in
> print("$var\n").
I would say that
print "$var" vs. print $var
is roughly equivalent to
if (scalar @a) vs. if (@a)
One makes the context explicit, the other leaves it implicit. Each one
works perfectly well, and the only difference is style.
I agree with Steve. I don't understand why people are wasting so much
time instigating a flame war over such a trivial point.
I would never use double-quotes around a lone scalar variable, even in
print(). But Steve would, his code works perfectly, and he prefers the
consistency with his other print statements. That's fine with me.
--
_ / ' _ / - aka -
( /)//)//)(//)/( Ronald J Kimball rjk@linguist.dartmouth.edu
/ http://www.tiac.net/users/chipmunk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Sat, 03 Jul 1999 16:24:22 GMT
From: tony@showroom.org.uk (Tony Kennick)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <377e384a.15344053@missy.shef.ac.uk>
abigail@delanet.com (Abigail) imparted the following:
:->Daniel Grisinger (dgris@moiraine.dimensional.com) wrote on MMCXXXI
:->September MCMXCIII in <URL:news:m34sjmx5tx.fsf@moiraine.dimensional.com>:
:->//
:->// Fortunately for the less experienced, there exists a collection of
:->// the world's best and brightest perl programmers, available 24 hours
:->// a day, 7 days a week on comp.lang.perl.misc, eager to share their
:->// occasionally painfully-won knowledge of which is the _best_ way to
:->// do something.
:->
:->
:->*sigh* If only those programmers would share something useful. Like
:->which colour nail polish to use with the green dress.
We definitely need more information than this, nail polish colour
depends on jewels and other accessories as much a dress colour. Also
useful is information about hair and eyes. According to informed
sources as 1999 turns into 19100 nail polish shades will darken and
eye shadow will get heavier.
--
From Tony Kennick aka Gonzo The Great
http://missy.shef.ac.uk/users/old-firm/
Gonzo: Slang for "the last man standing
at a drinking marathon"
------------------------------
Date: Sat, 03 Jul 1999 16:52:43 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <37803ef9.2300149@news.skynet.be>
Uri Guttman wrote:
>print "$var" is a semantic issue. tad has explained it several times to
>you. it TELLS the human reader that there is some interpolation going on
>here other than the single var. it matters not that print will stringify
>the var anyway. so it is MISLEADING to the next person who reads the
>code.
Uh... You could turn that around. print() stringifies it's parameters,
and "$var" says that the parameter is stringified. In this case, it only
stresses what is actually happening...
#! perl -w
my $var = new Autodereference ("Hi there!");
print "Plain var: ";
print $var;
print "\n";
print "Stringified: ";
print "$var";
print "\n";
package Autodereference;
use overload '""' => \&stringify;
sub stringify {
my $self = shift;
return "VALUE = \"$self->{VALUE}\"";
}
sub new {
my $class = shift;
my $me = { VALUE => shift };
return bless $me, $class;
}
__END__
-->
Plain var: VALUE = "Hi there!"
Stringified: VALUE = "Hi there!"
I really can't see what "black magic" you'd expect that isn't already
happening, anyway.
Bart.
------------------------------
Date: 03 Jul 1999 13:51:56 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <x7u2rlzkn7.fsf@home.sysarch.com>
>>>>> "SL" == Steve Lamb <morpheus@despair.rpglink.com> writes:
SL> On 03 Jul 1999 10:46:41 -0400, Uri Guttman <uri@sysarch.com>
SL> wrote:
>> ok, let me make this clear. this is not a style issue, but a
>> semantic one. do you knwo the difference between those two terms?
SL> Yes, I do.
you obviously do not.
>> indenting, names, whitespace are all style issues. using a foreach
>> loop vs. a foreach modifier is style. using || or unless is style.
SL> Doublequotes on print is a style issue as well.
no as it affects the maintenance which is more than style.
>> it TELLS the human reader that there is some interpolation going on
>> here other than the single var.
SL> If that were the case, people would be advocating
SL> print($var,"\n") to TELL the human reader WHERE, exactly, that is
SL> happening. Since you, nor anyone else, is advocating that, it is
SL> style. *plonk*
i never advocated $var,"\n". so why are you blabbering it. you bounce
from one extreme to another about what we say. i said that quoting a
lone var is misleading. if you want a newline then putting the var in
quotes with newline is clearer.
and you don't even know what *plonk* means. if you did you would't be
seeing these posts.
SL> No, I'm pointing out that the reasons you're giving are
SL> complete and utter bullshit because you don't take it to the
SL> logical conclusion as I have pointed out about a dozen times now.
SL> It is like the religious right who quote the story of Lot/Sodam as
SL> being agaist homosexuality and blatently ignore the fact that Lot
SL> offered up his daughters as cheap whores. You are saying, "Do it
SL> this way, because I say so because of this reason" yet when I take
SL> that same reason (story) and point out that if you truely believed
SL> it you would do it another way (offer up your daughters as whores)
SL> you conveniently ignore that point and reiterate, "Do it this way,
SL> because I say so."
oh, oh! homosexuallity and the bible have entered the thread. i hereby
bring the wrath of godwin on you and state your perl style is worse than
hitler's. he was a lousy perl hacker.
>> it is not a STYLE issue but a SEMANTIC one.
SL> Until you, and everyone else, starts advocating
SL> print($var."\n"), it is most certainly style.
not really. that is stupid as it does an extra operation. do you know
the difference between "$var\n" and $var . "\n"? what the compiler does?
what the run time does? what the semantics are? what you are trying to
convery to the reader of the code?
>> code is for humans and not for computers. the maintainer of your
>> code will curse you out (more than you have seen here) for putting
>> quotes where it is NOT NEEDED and making him wonder why they were
>> put there.
SL> Oh, you mean like print("$var\n") when the variable doesn't
SL> need to be in the quotes?
it is indicating a string is being printed with interpolated stuff. it
is not needed but used to convey important information to the reader of
the code. you don't get maintenance issues at all, do you?
SL> No, I am pointing out that advocating print($var) and stating
SL> print("$var\n") is acceptable instead of advocating
SL> print($var."\n") is hypocritical. I don't like hypocrits,
SL> esp. when it comes to snotty brats like you and Tom.
i blow out my nose at you and fart in your general dfirection.
and i never advocated what you claim. chow me one pice of code i have
posted where i use print( $var . "\n" ). use dejanews if you can. i dare
you. i double dare you. i triple dog dare you! (fans of "a christmas
story" will get the last one)
>> because that is inconsistant. why do you single out print to have
>> quotes on naked vars while other functions don't?
SL> Because print is, in my mind, like the verb "to say".
no, it is the print function. it is not a verb but a perl function. in
the same vein would you say join( "$var", @list )? join stringifies its
first argument. what about "$var" x $count? same dumb use of quotes. so
where is your vaunted consistancy now?
SL> Yet there is an inconsistancy in that print is also one of the
SL> very few functions which, in more cases than not, it will have
SL> strings quoted in one fastion or another yet you chose not to have
SL> it quoted just because it is a single var. I am well aware of the
SL> "inconsistancy" when compared to other functions. But each
SL> function is different, isn't it?
what about using here docs? does print <<"HERE" look good to you too?
>> it is NOT A LEGALITY issue. do you get it? no one said it is
>> illegal to do anything syntactically correct in perl.
SL> I beg to differ. Wasn't it Tom who said it was dangerous and
SL> wrong? :P
that doesn't mean illegal. you have no grasp on english either. wrong
and dangerous is not illegal. it is illegal if perl syntax prohibits
it. it is wrong or dangerous if it will lead to bugs or cause
maintenance problems at some time in the future. if you understood
english better, you could actually participate in discussions withou
coming off like a fool.
SL> Actually, yes, I have, happens all the forking time in my job.
SL> Perl, of course, makes it worse because there are several ways to
SL> do things, which I have pointed out.
so don't use perl. use some strightjacketed language if you please. we
are not telling you to use perl, just telling you to use it better. but
as we always sem to have one long flame war here with some miscreant who
doesn't grok perl and its ways, we have to put up with idiots like you.
SL> It is a stupid practice because of what? You still have not
SL> explained it because you insist, apparently, that print("$var\n")
SL> is acceptable when, clearly, by your OWN ARGUEMENT
SL> print($var,"\n") is the "correct" way to do it. Hypocrits, when
SL> they have their hypocricy pointed out to them, have no arguement
SL> left. Good bye. You bore me.
now you say print( $var, "\n" ). what happened to the . version (which i
quote again?
SL> print($var."\n")
talk about inconsistancy. they are two very different animals. you can't
even stay focused on which version or the code we are advocating (even
when we are advocating neither).
just shows to go ya, you can't argue with an inconsistant mind.
please go away and learn some logic.
and while i can flame and throw the curses with the boys of south park,
i won't waste any on you as you have in this group.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.
------------------------------
Date: 3 Jul 1999 16:00:14 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <slrn7nsuea.31h.abigail@alexandra.delanet.com>
Uri Guttman (uri@sysarch.com) wrote on MMCXXXII September MCMXCIII in
<URL:news:x7zp1dzt7y.fsf@home.sysarch.com>:
##
## print "$var" is a semantic issue. tad has explained it several times to
## you. it TELLS the human reader that there is some interpolation going on
## here other than the single var.
I use print "$var" sometimes. Often because I first printed "$var\n",
and then removed the newline. I can't always be bothered to remove
the quotes as well. Or maybe I just wanted to type 'print "$var\n"',
and I changed my mind between the 'v' and the 'a'.
Abigail
--
perl -wle 'print "Prime" if (0 x shift) !~ m 0^\0?$|^(\0\0+?)\1+$0'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 3 Jul 1999 16:03:17 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <slrn7nsuk3.31h.abigail@alexandra.delanet.com>
Uri Guttman (uri@sysarch.com) wrote on MMCXXXII September MCMXCIII in
<URL:news:x7zp1dzt7y.fsf@home.sysarch.com>:
^^
^^ print "$var" is a semantic issue. tad has explained it several times to
^^ you. it TELLS the human reader that there is some interpolation going on
^^ here other than the single var. it matters not that print will stringify
^^ the var anyway. so it is MISLEADING to the next person who reads the
^^ code.
I wonder if I really want my code to be maintained by someone who gets
mislead by 'print "$var";'.
Abigail
--
perl -we 'print split /(?=(.*))/s => "Just another Perl Hacker\n";'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Sat, 03 Jul 1999 17:32:00 -0400
From: Steve Palincsar <palincss@his.com>
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <377E8150.E39C0AC3@his.com>
Steve Lamb wrote:
>
> All of this because I choose to place double-quotes around my print
> statements unless there is a compelling reason not to (print(@foo) for
> example) and one individual decided to ignore me saying that and take it to
> the scope of ALL functions which, in case people have missed it (which they
> did) I agree is a bad thing. Jeez.
>
> So, where is the risk. I am now waiting for you to tell me a case where
> $var must be print($var) or be harmed when it is perfectly legal in
> print("$var\n").
It's best to write idiomatic code. It's what other readers expect,
and what
is "normal". That doesn't mean it's necessarily *WRONG* to use
peculiar
constructions, but it does cause needless confusion, slows down the
reader,
and in general _looks wrong_.
------------------------------
Date: 3 Jul 1999 23:29:06 -0400
From: sandoz@umbc.edu (James W. Sandoz)
Subject: Re: 2 simple (not to me tho) questions
Message-Id: <7lmke2$2of8c@umbc7.umbc.edu>
<other stuff deleted>
Uri Guttman:
"not really. that is stupid as it does an extra operation. do you
know the difference between "$var\n" and $var . "\n"? what the
compiler does? what the run time does? what the semantics are?
what you are trying to convery to the reader of the code?"
Wow! I wouldn't have considered the run times of these. I
benchmarked them. The results are below. I comes to about a 2 - 3 %
difference, "$i\n" being faster. Code is at end of post.
Benchmark:
1000000 iterations:
$i ."\n" took 55 secs (55.04 usr 0.05 sys = 55.09 cpu)
"$i\n" took 54 secs (53.84 usr 0.04 sys = 53.88 cpu)
Uri Guttman:
"i double dare you. i triple dog dare you! (fans of "a
christmas story" will get the last one)"
I believe Jean Shepherd used this in other stories as well.
As a lurker and very occasional poster, I've learned from experience
that reading is not necessarily understanding (One of my posted
questions was answered in a faq which I had read. The responses
explained the faq and asked what I hadn't understood. I had simply
misread what -n does. It's clear and concise in the faq, but I'd
missed it. Completely.) My point: I doubt that Mr. Lamb, who has
had the difference between 'print $a' and 'print "$a"' explained
several times is focused on other things and won't understand the
difference until he's good and ready. Or he does understand the
difference and doesn't care. In either case, I suspect that any
further clarifications will serve only to aggravate him.
For What It's Worth: My perception of the responses by the biggies on
this group has morphed from amazement at the audacity and arrogance to
appreciation of the wisdom. And no. I'm not just saying that because
I'll be starting a major rewrite of what is to me a major Perl program
and I just might need advice here. ;)
Jim Sandoz
Benchmark code:
#!/usr/local/bin/perl5 -w/usr/local/bin/perl5 -w
uuse Benchmark;
uuse diagnostics;
open (OUT, ">>/dev/null") or die "Can't find dev/null. $!\n";
$start = new Benchmark;
for ($i=0; $i<1000000; $i++) {
print (OUT $i ."\n");
}
$end = new Benchmark;
print "$i iterations:\n";
print "\$i .\"\\n\" took ", timestr(timediff($end, $start)). "\n";
$start1 = new Benchmark;
for ($i=0; $i < 1000000; $i++) {
print (OUT "$i\n");
}
$end1 = new Benchmark;
print "\"\$i\\n\" took ", timestr(timediff($end1, $start1)). "\n";
--
Mr. James W. Sandoz, Instructor, UMBC Dept of Biol Sciences,
1000 Hilltop Circle
Catonsville, MD 21250
voice: (410) 455-3497; fax: 455-3875; net: sandoz@umbc.edu
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 99)
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V9 Issue 20
************************************
