in reply to Re^7: Assignable Subroutines
in thread Assignable Subroutines

I expect that the inefficient copying you're worried about would happen either way.

Actually, no. With the current implementation, the lvalue method gives the substitution operator direct access to the underlying memory. Indeed, it this desire to retain this efficient, direct access that is behind TimToady's reluctance to change the current mechanism for one that would allow validation. I like the ability to achieve that efficiency, but not so much that I wouldn't give it up for the ability to verify the assignment.

But the efficiency is only one of the list of benefits I outlined. Most of the others, including 2 or 3 that I thought would be very close to your heart--those that prevent the possibilities of errors being introduced--are much more relevant and desirable.

I fail to understand how you can find: $obj->thing =~ s[this][that]g;

confusing, but not $string =~ s[this][that]g;?

But maybe the question is not how, but why!


Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^9: Assignable Subroutines
by perrin (Chancellor) on Jan 25, 2005 at 21:00 UTC
    $string =~ s[this][that]g operates on a variable. It isn't the easiest thing to read, but it's been around so long that we've all gotten used to it. The syntax you're proposing has too much going on in one line. It's not even operating on the method, but on the return value of the method. And then does it call the method again to set the new value, or do some kind of implicit referencing? It's not obvious.

    I didn't respond to the other benefits you listed because all of them less important than readability. The current syntax doesn't seem cumbersome to me.