$obj->thing(15000, 20000) =~ s[something][else]g;
[download]

might be easier to read as:

  $spreadsheet->cell('C3', 'D4') =~ s[something][else]g;
[download]

There has to be a clean, and I mean absolutely clean, way of doing this - which P6 is either giving to us, or will get us very close to. What we have in P5 is not even close:

  # current lvalue sub:
  (my $val = $spreadsheet->cell('C3', 'D4')) =~ s[something][else]g;
  $spreadsheet->cell('C3', 'D4') = $val;
  $spreadsheet->recalc() if $spreadsheet->autorecalc();

  # without lvalue sub:
  (my $val = $spreadsheet->cell('C3', 'D4')) =~ s[something][else]g;
  $spreadsheet->cell('C3', 'D4', $val);
[download]

A world of difference syntactically in the problem domains where this makes sense. With the current lvalue sub, you can't hook in after the assignment to do things (such as validation, or, as above, recalculating the sheet). Without the lvalue sub, we can do this, but syntactically it's a bit more awkward.

I dislike both syntaxes for assignment of values. I would suspect.. $spreadSheet->getCell('C1','C5')->setValue('123');

Biggest reason to have the Cell as an object is that a cell isn't a string. It's an object that contains a value. In fact, in spreadsheet context, it has other attributes, such as formatting, margins and other sillinesses...

----
Give me strength for today.. I will not talk it away..
Just for a moment.. It will burn through the clouds.. and shine down on me.

If it's just combining two setters into one call, ...

How on earth did you reach that conclusion?

This syntax is standard perl and works now. Is my use of [] so confusing?

You've never used

substr( $buffer, $n, $m ) =~ s[this][that]g;
[download]

Note, this might be direct access to an internal buffer, but it could equally be a subset of a bigger than memory file, or a BLOB queried from a DB.

The problem is that, you cannot do anything afterwards.

So, for example, in the latter case, you could not arrange for the modified BLOB to be written back to the DB.

Of course, the alternative syntax is:

my $temp =  $obj->get_thing( 15000, 20000 );
$temp =~ s[this][that]g;
$obj->set_thing( 15000, 200000, $temp );
[download]

which besides the:

1. inconvenient notation;
2. requirement for a temporary variable;
3. the inefficiency of copying large chunks of data around unnecessarially.
4. The need for two nearly identical pieces of code.
5. and the potential for someone to come along and stick some other lines of code between two halves of what should be an "atomic" operation.

Did you notice the typo?

I had the wierdest of thoughts (ain't TMTOWTDI wonderful?) ...

sub update_thing
{
  my ($self, $x, $y, $u) = @_;
  if (ref $u and UNIVERSAL::isa($u, 'CODE'))
  {
    # use temp to keep the $u function from changing $_[0] ;-)
    my $val = $self->{cell}[$x][$y];
    $u = $u->($val);
  }
  # validate $u.
  if ($is_valid)
  {
    $self->{cell}[$x][$y] = $u;
}
[download]

called sorta like:

  $obj->update_thing(15000, 20000, sub { $_[0] =~ s[something][else]g;
+ $_[0] } );
[download]

No, not better than $obj->thing(15000,2000) =~ s[something][else]g. But a bit better than the other ideas going around, maybe? :-) If not better, at least different...

It's a fine notion but it has it's problems.

You now, need to code

• a get_thing() method;

  print $obj->thing;
  [download]

• a set_thing() method;

  $obj->thing = 'someting';
  [download]

• a update_thing() method;

  $obj->thing =~ s[this][that]g;
  [download]

• a return_list_of_matched_subthings() method;

  my @subthings = $obj->thing =~ m[subthing]g;
  [download]

• a return_count_of_subthings() method;

  my $count = $obj->thing =~ m[subthing]g;
  [download]

• a get_subthing_iterator() method;

  while( $obj->thing =~ m[subthing]g ) {
      last if substr( $obj->thing, pos( $obj->thing ) - 22, 22 ) 
           eq 'This is *the* subthing';
  }
  [download]

  (Oh! And a substr_thing() method;)

• a preincr_thing() method;

  $obj->thing++;
  [download]

• A postincr_thing() method;

  ++$obj->thing;
  [download]

• (pre/post decr etc. etc)

And all the others that you effectively get for free with a single lvalue method.

All that is missing is a convenient way to validate the assignment.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

So it would seem you have answered my question: do the arguments get passed to both the setter and the getter or does only one of them get them. On reflection i suppose "both of them" is the obvious choice....

---
demerphq

How on earth did you reach that conclusion?

It's confusing syntax. I thought you were assigning the return value of running the regex on the return value of your method call.

You've never used substr( $buffer, $n, $m ) =~ s[this][that]g; ?

No, I find that hard to read. I would use a temp variable there. Your alternative syntax example looks much clearer to me. I expect that the inefficient copying you're worried about would happen either way.

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.

I think you're missing the point, the pseudo-code id consider more or less equivelent to what BrowserUK wrote is:

#$obj->thing( 15000, 20000 ) =~ s[something][else]g;
{
  my $tmp=$obj->thing();
  $tmp =~ s[something][else]g;
  $obj->thing(15000,20000,$tmp);
}
[download]

I suspect we could debate about exactly how this one should perform (omitting the arguments its easy but whether the arguments belong to the setter, the getter or both is a debate probably worth having.)