>I wasn't referring to the lvaluability of assignment. Which does confuse
>me, but only from the scoping of 'my' in something like (my $foo = $bar)
>+= 10. Which is very different from while(my $foo=bar) {...}.
The scoping of declarations in control statements is very special.
Consider what happ
>Uri Guttman wrote:
>>
>> TC> ($this = $that) =~ s/foo/bar/;
>> TC> for (@these = @those) { s/foo/bar/ }
>>
>> TC> You can't really do those in one step without it.
>RFC 164 v2 has a new syntax that lets you do the above or, if you want:
> $this = s/foo/bar/, $that;
> @these
Uri Guttman wrote:
> but we need a better syntax for s/// that doesn't modify its string but
> returns a copy which has had the substitution applied to it. possibly a
> s/// modifier?
>
> $new = $old =~ s/foo/bar/n ;
>
> n for new?
if our internal string representation could grow from
>I was referring to the visual similarity of = and =~, when in fact they
>have nothing to do with one another. The expression I picked is just a
>frequently encountered idiom that puts the two in close proximity. Your
>proposed ~ thing would make it much rarer, but I still think =~ looks
>like som
> TC> ($this = $that) =~ s/foo/bar/;
> TC> for (@these = @those) { s/foo/bar/ }
> TC> You can't really do those in one step without it.
>but do they really need to be combined into one step? i sometimes prefer
>the separate assignment statement for clarity. other times i feel i am
>
>RFC 164 v2 has a new syntax that lets you do the above or, if you want:
> $this = s/foo/bar/, $that;
> @these = s/foo/bar/, @those;
>Consistent with split, join, splice, etc, etc.
That looks tremendously *IN*consistent, since now you must alter
the laws of precedence! :-(
% perl -MO=D
I keep noticing the connection between
$foo =~ /whatever/;
$foo->whatever;
for ($foo) { whatever }
They're all topicalizers.
--tom
Mike Lambert wrote:
>
> or even:
> @a = s/a+/a/, @a;
This is actually the native syntax from RFC 164.
> Basically, the argument is that you could theoretically do @a =~ s/a+/a/
> with QS, along with many other things. So perhaps, imo, it would be best
> to just let QS handle it.
I'm fine with t
On Wed, 30 Aug 2000, Nathan Wiger wrote:
> RFC 164 v2 has a new syntax that lets you do the above or, if you want:
>
>$this = s/foo/bar/, $that;
>@these = s/foo/bar/, @those;
>
> See RFC 164 v2, all this is supported, as well as this:
>
>@str =~ s/foo/bar/;
>
> Which has been a pi
Nathan Wiger wrote:
[...]
> RFC 164 v2 has a new syntax that lets you do the above or, if you want:
>
>$this = s/foo/bar/, $that;
>@these = s/foo/bar/, @those;
>
> Consistent with split, join, splice, etc, etc.
I often use the comma operator like this
s/foo/bar/, $n++ if $x;
If "s"
Tom Christiansen wrote:
>
> >($foo = $bar) =~ s/x/y/; will never make much sense to me.
>
> What about these, which are much the same thing in that they all
> use the lvaluability of assignment:
>
> chomp($line = );
> ($foo = $bar) += 10;
> ($foo += 3) *= 2;
> func($diddle_me =
Uri Guttman wrote:
>
> TC> ($this = $that) =~ s/foo/bar/;
> TC> for (@these = @those) { s/foo/bar/ }
>
> TC> You can't really do those in one step without it.
RFC 164 v2 has a new syntax that lets you do the above or, if you want:
$this = s/foo/bar/, $that;
@these = s/foo/b
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> who uses select directly anymore? use a module! :)
TC> I see the smiley, but one must be exceedingly careful not to
TC> enshrine one's own personal preferences and predilections--one's
TC> own small choices of style and nuance
> TC> ($foo += 3) *= 2;
>that is way too many assignment ops. better is the normalized
> $foo = ($foo + 3) * 2;
> TC> $n = select($rout=$rin, $wout=$win, $eout=$ein, 2.5);
>who uses select directly anymore? use a module! :)
I see the smiley, but one must be exceedingly careful
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> ($foo = $bar) =~ s/x/y/; will never make much sense to me.
TC> What about these, which are much the same thing in that they all
TC> use the lvaluability of assignment:
TC> chomp($line = );
TC> ($foo = $bar) += 10;
Steve Fink wrote:
>
> Hm. Larry didn't really like anything that would reverse the order of
> the pattern and the expression to be matched against, and I think I
> agree at least that it should always be possible to put the direct
> object at the beginning, preferably in a way usable by more than
>What about these, which are much the same thing in that they all
>use the lvaluability of assignment:
And don't forget:
for (@new = @old) { s/foo/bar/ }
--tom
>($foo = $bar) =~ s/x/y/; will never make much sense to me.
What about these, which are much the same thing in that they all
use the lvaluability of assignment:
chomp($line = );
($foo = $bar) += 10;
($foo += 3) *= 2;
func($diddle_me = $protect_me);
$n = select($rout=$rin, $w
> > RFC138: Eliminate =~ operator.
>
> > RFC164: Replace =~, !~, m//, and s/// with match() and subst()
>
> Which I could see unifying. I'd ask people to wait until v2 of RFC 164
> comes up. It may well include everything from RFC 138 already.
Hm. Larry didn't really like anything that would re
Mark-Jason Dominus wrote:
>
> RFC135: Require explicit m on matches, even with ?? and // as delimiters.
This one is along a different line from these two:
> RFC138: Eliminate =~ operator.
> RFC164: Replace =~, !~, m//, and s/// with match() and subst()
Which I could see unifying. I'd ask peo
Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis
pered:
|
| RFC135: Require explicit m on matches, even with ?? and // as delimiters.
|
| RFC138: Eliminate =~ operator.
|
| RFC164: Replace =~, !~, m//, and s/// with match() and subst()
|
| I would like to see
21 matches
Mail list logo
