in reply to Re^2: Inline substitution regex
in thread Inline substitution regex

It's hard to see s/this/that/ as an opperator! Because, err ... it looks like an expression

s/this/that/ *is* an expression. The expression consists of the substitution operator and its two operands (the search pattern and the replacement expression).

$text =~ s/this/that/ is also an expression. The expression consists of the binding operator (=~) and its two operands, the value to bind ($text) and the previously mentioned expression.

The binding operator does not return its LHS. It returns its RHS. As for the substitution operator, it does not return the variable to which it is bound.

the following which prints 7 as expected.

I'm not sure what you are saying. Are you saying $var = 3+4 returns the result of 3+4, so $text =~ s/this/that/ should return the result of s/this/that? That's wrong for two reasons.

I didn't say it's not possible for an operator to return it's LHS. As you've shown, scalar assignment returns its left-hand side. There's also boolean operators. They return either their LHS or RHS operands.

Better solution:

foreach (keys %{$ref_cookie}) { push @{$self->{cookies}}, /^-(.*)/, $ref_cookie->{$_}; }

The match operator returns what it captures.

Update: Remove trailing paren

Replies are listed 'Best First'.
Re^4: Inline substitution regex
by vitoco (Hermit) on Sep 29, 2009 at 13:26 UTC

    Just guessing, shouldn't the solution be:

    foreach (keys %{$ref_cookie}) { push @{$self->{cookies}}, /^-(.*)/, $ref_cookie->{$1}); }

    ?

    Or the curly brackets from the failing original code isolate $_ and the substitution does not affect the last parameter of push?

    # push(@{$self->{cookies}}, {$_=~s/^-//}, $ref_cookie->{$_}});

      Your solution is definitely buggy.

      Let's say %$ref_cookie contains

      -foo => 'food', -bar => 'bard'

      The solution you propose would push

      'foo', undef, 'bar', undef -or- 'bar', undef, 'foo', undef (depending on the order the keys are returned)

      That's obviously not what he wants. He would just use undef if so.

      Fine, you'll say %$ref_cookie should contain

      -foo => 'food', foo => 'fool', -bar => 'bard', bar => 'barl'

      The solution you propose would push

      'foo', 'fool', 'fool', 'bar', 'barl', 'barl' -or- 'foo', 'fool', 'fool', 'fool', 'bar', 'barl' -or- undef, undef, 'bar', 'barl', 'foo', 'fool' -or- ... (depending on the order the keys are returned)

      It makes no sense. I suspect the OP wants

      'foo', 'food', 'bar', 'bard' -or- 'bar', 'bard', 'foo', 'food' (depending on the order the keys are returned)

      That is achieved using the solution I proposed.

        Wow, that was an unexpected answer... :-)

        With post "I should've known better!" in mind, I was trying to understand if $_ is modified only in the scope of the substitution from the OP's attempt:

        foreach (keys %{$ref_cookie}) { push(@{$self->{cookies}}, {$_=~s/^-//}, $ref_cookie->{$_}}); }

        I didn't pay much attention on the context or what keys should be. I see your point and agree.

        Now, if OP has both types of keys, with and without leading hashes:

        -foo => 'food', bar => 'barl'

        the code should be:

        push @{$self->{cookies}}, /^-?(.*)/, $ref_cookie->{$_};

        to get all four values in the array.

        BTW, I'll have to practice more with push of undef in arrays...