Difference between "$var" and $var?
shar...@hotmail.com
Is there any advantage in the assignment operation
$dest = "$src" over
$dest = $src ?
And then, are the following operations identical?
$dest = "$varA:$varB:$varC";
$dest = join ":", $varA, $varB, $varC;
Regards,
--Rakesh
Andrew DeFaria
Hi,
Is there any advantage in the assignment operation
$dest = "$src" over
$dest = $src ?
$dest = $src over
$dest = "$src"
And then, are the following operations identical?
$dest = "$varA:$varB:$varC";
$dest = join ":", $varA, $varB, $varC;
shar...@hotmail.com
> On 12/18/2009 11:42 AM,shar...@hotmail.comwrote:Hi,
> Is there any advantage in the assignment operation
> $dest = "$src" over
> $dest = "$varA:$varB:$varC";
What advantage is there? Would you explain some more.
And why then does that advantage not happen in case
of the 'join' example?
--Rakesh
Uri Guttman
sr> Hi,
sr> Is there any advantage in the assignment operation
sr> $dest = "$src" over
sr> $dest = $src ?
this has been covered many times here in particular by tad. the "$src"
is not good in general. it makes an unneeded extra copy of the value. it
also can be a bug in that it stringifies the value and since it is a
copy, if a sub wanted to modify it in place, it would fail. the rule is
not to quote single scalar variables unless you really want a copy.
sr> And then, are the following operations identical?
sr> $dest = "$varA:$varB:$varC";
sr> $dest = join ":", $varA, $varB, $varC;
did you compare the results? did you see any differences? make up your
own mind about that.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
Jochen Lehmeier
> What advantage is there? Would you explain some more.
They are just different from each other.
$a = $b simply assigns $b to $a, no matter what $b is. If $b==undef, then
$a will be assigned undef. If $b is a reference to something, $a will be
the same reference.
$a = "$b" transforms $b into a string and then assigns that string to $a.
When $b==undef, then $a will still be assigned "". So there can be a
difference between $a and $b afterwards. If $b is a reference to
something, $a will be the string "HASH(0x1239234)" or whatever, that is,
something totally different.
> And why then does that advantage not happen in case
> of the 'join' example?
'perldof -f join' says "Joins the separate strings of LIST into a single
string". So join transforms the variables it is joining into strings
anyway, so it doesn't differ from "$a:$b:$c".
shar...@hotmail.com
I didnt see any difference in "$var" & $var. So does that mean there's
no difference?
shar...@hotmail.com
wrote:
Thanks for clarifying my doubts.
-- Rakesh
John Bokma
> did you compare the results? did you see any differences? make up your
> own mind about that.
I think that's a bit unfair. I mean, you *don't* have to post a reply.
--
John Bokma
Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/
jl_...@hotmail.com
> Is there any advantage in the assignment operation
> $dest = "$src" over
> $dest = $src ?
I don't really have anything new to add (that hasn't been already
stated by other posters), but I thought I might mention the following
perldoc FAQ:
perldoc -q "always quoting"
What's wrong with always quoting "$vars"?
Cheers,
-- Jean-Luc
Uri Guttman
sr> On Dec 19, 12:14�am, "Uri Guttman" <u...@StemSystems.com> wrote:
>> >>>>> "sr" == sharma r <sharma...@hotmail.com> writes:
>>
>> � sr> Hi,
>> � sr> Is there any advantage in the assignment operation
>> � sr> � $dest = "$src" over
>> � sr> � $dest = $src � �?
>>
>> this has been covered many times here in particular by tad. the "$src"
>> is not good in general. it makes an unneeded extra copy of the value. it
>> also can be a bug in that it stringifies the value and since it is a
>> copy, if a sub wanted to modify it in place, it would fail. the rule is
>> not to quote single scalar variables unless you really want a copy.
>>
>> � sr> And then, are the following operations identical?
>> � sr> � $dest = "$varA:$varB:$varC";
>> � sr> � $dest = join ":", $varA, $varB, $varC;
>>
>> did you compare the results? did you see any differences? make up your
>> own mind about that.
sr> I didnt see any difference in "$var" & $var. So does that mean there's
sr> no difference?
please read what i said. i said check the difference in the $dest
things. my comments on "$src" were above that. i didn't say the same
things about both questions.
Uri Guttman
JB> "Uri Guttman" <u...@StemSystems.com> writes:
>> did you compare the results? did you see any differences? make up your
>> own mind about that.
JB> I think that's a bit unfair. I mean, you *don't* have to post a reply.
no, i wanted to really know if he actually compared the output. he was
asking almost as if he didn't know.
David Filmer
>>> Difference between "$var" and $var?
Sometimes you will want to "stringify" an object. For example,
consider the following snippet, which uses the IO::All module to find
all the .txt files in a particular directory, which are added to a
zipfile.
my $zip = Archive::Zip -> new();
foreach my $file (io('/tmp/test/')
-> filter(sub {$_->name =~/.*\.txt/})
-> all_files(1) ) {
print "Adding file $file\n";
$zip -> addFile($file);
}
$zip->writeToFileNamed( 'baz.zip' );
If you run that as-is, the zipfile will be empty, even though you see
multiple print statements.
The problem is that $file is not an ordinary scalar variable - it's an
IO::All blessed something-or-another (Dumper says: $file = bless
( \*Symbol::GEN2, 'IO::All::File' ); ). In order to make that code
work, you need to double-quote $file (which causes it to "strinigy" to
it's name):
$zip -> addFile("$file");
--
David Filmer (http://DavidFilmer.com)
John Bokma
>>>>>> "JB" == John Bokma <jo...@castleamber.com> writes:
>
> JB> "Uri Guttman" <u...@StemSystems.com> writes:
> >> did you compare the results? did you see any differences? make up your
> >> own mind about that.
>
> JB> I think that's a bit unfair. I mean, you *don't* have to post a reply.
>
> no, i wanted to really know if he actually compared the output. he was
> asking almost as if he didn't know.
I am not a fan of trial and error coding and certainly wouldn't
stimulate it.
I've been back to usenet recently and read both this group and
comp.lang.python and (again) sadly have to notice that this group is far
more hostile. Just don't reply to a message if it annoys you. I hit
Ctrl+C k (kill reply) a lot nowadays after I pressed F (follow-up).
Justin C
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>
> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
> <style type="text/css">
> body {
> font: Helvetica, Arial, sans-serif;
> }
> p {
> font: Helvetica, Arial, sans-serif;
> }
> .standout {
[snip]
Please don't do that. This is usenet where many people use text-only
readers - it is, after all, only text that we're exchanging.
I have no idea what you said, there was way too much html to wade
through to find your post.
Justin.
--
Justin C, by the sea.
Martijn Lievaart
> Please don't do that. This is usenet where many people use text-only
> readers - it is, after all, only text that we're exchanging.
>
> I have no idea what you said, there was way too much html to wade
> through to find your post.
He's been told that many times, but he doesn't care. Killfile him and
forget.
M4
Andrew DeFaria
On 12/19/2009 03:17 AM, Justin C wrote:
In article <4b2bc3eb$0$1324$815e...@news.qwest.net>, Andrew DeFaria wrote:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<style type="text/css">
body {
font: Helvetica, Arial, sans-serif;
}
p {
font: Helvetica, Arial, sans-serif;
}
.standout {
[snip]
Please don't do that. This is usenet where many people use text-only
readers - it is, after all, only text that we're exchanging.
I have no idea what you said, there was way too much html to wade
through to find your post.
Andrew DeFaria
I still say a church steeple with a lightning rod on top shows a lack of confidence.
Peter J. Holzer
>>>>>> "sr" == sharma r <shar...@hotmail.com> writes:
>
> sr> On Dec 19, 12:14�am, "Uri Guttman" <u...@StemSystems.com> wrote:
> >> >>>>> "sr" == sharma r <sharma...@hotmail.com> writes:
> >>
> >> � sr> Hi,
> >> � sr> Is there any advantage in the assignment operation
> >> � sr> � $dest = "$src" over
> >> � sr> � $dest = $src � �?
> >>
> >> this has been covered many times here in particular by tad. the
> >> "$src" is not good in general. it makes an unneeded extra copy of
> >> the value. it also can be a bug in that it stringifies the value
> >> and since it is a copy, if a sub wanted to modify it in place, it
> >> would fail. the rule is not to quote single scalar variables
> >> unless you really want a copy.
> >>
> >> � sr> And then, are the following operations identical?
> >> � sr> � $dest = "$varA:$varB:$varC";
> >> � sr> � $dest = join ":", $varA, $varB, $varC;
> >>
> >> did you compare the results? did you see any differences? make up your
> >> own mind about that.
>
> sr> I didnt see any difference in "$var" & $var. So does that mean there's
> sr> no difference?
>
> please read what i said. i said check the difference in the $dest
> things. my comments on "$src" were above that. i didn't say the same
> things about both questions.
Irrelevant. If you think Sharma could have found out whether
$dest = "$varA:$varB:$varC";
and
$dest = join ":", $varA, $varB, $varC;
are equivalent by just trying it with a few random values, why should he
not be able to do the same thing with
$dest = "$src";
and
$dest = $src;
?
If you already know about the difference between "$src" and $src it is
easy enough to come up with an example which demonstrates it. But I
doubt you would stumble upon it by random testing. So as Sharma noted,
the mere fact that your tests don't show any difference doesn't mean
there isn't any. To convince yourself that
$dest = "$varA:$varB:$varC";
and
$dest = join ":", $varA, $varB, $varC;
do the same thing you have to reason about it:
$dest = "$varA:$varB:$varC";
stringifies each of $varA, $varB and $varC, and then concatenates them
with a ":" between them.
$dest = join ":", $varA, $varB, $varC;
stringifies each of $varA, $varB and $varC, and then concatenates them
with a ":" between them.
So they are the same. Or at least I think they are, because in Perl
stringification may change the SV (it adds a PV slot), and while it is
obvious that this will happen in "$varA:$varB:$varC", it isn't quite so
obvious in the join case. (And I don't think anybody who isn't already
very familiar with Perl would use the word "obvious" in this context ;-)).
hp
Peter J. Holzer
> If you already know about the difference between "$src" and $src it is
> easy enough to come up with an example which demonstrates it.
And I'm very glad I didn't post the example I came up with because
Jochen's examples are so much better.
hp
s...@netherlands.com
Late to this, I see you got your answer, but have some stuff to add.
I don't think your question is if there is an advantage of
> $dest = "$src" over
> $dest = $src ?
is it?
To answer your question, you have to answer this question.
Isin't it really a question of what is a '$var' Perl data type?
I know it sounds trivial, but sooner or later this will come
up again and again. Like take boolean's for example.
This should lead you to the docs on data types, 'perldata'.
Its better to get the full picture instead of a thread of info
at a time.
perldata:
-----------------
Perl has three built-in data types:
scalars, arrays of scalars, and associative arrays of scalars,
known as "hashes".
'Scalar Values'
All data in Perl is a scalar, an array of scalars, or a hash of scalars.
A scalar may contain one single value in any of three different flavors:
a number, a string, or a reference.
In general, conversion from one form to another is transparent.
Although a scalar may not directly hold multiple values, it may contain
a reference to an array or hash which in turn contains multiple values.
...
Although strings and numbers are considered pretty much the same thing
for nearly all purposes, references are strongly-typed, uncastable
pointers with builtin reference-counting and destructor invocation.
...
---------------
So given that last part about references, it would throw a monkey wrench
in the notion that $var and "$var" are always equal.
Who knows, using booleans, you may run into context situations:
65 == "65" true
65 eq "65" true
65 eq "A" false
65 == "A" warning, "A" is not a digit
-sln