Thread overview
.length and lvalue?
Aug 23, 2005
Fredrik Olsson
Aug 23, 2005
Manfred Nowak
Aug 23, 2005
Fredrik Olsson
Aug 23, 2005
Derek Parnell
August 23, 2005
Is there a technical problem that hinders these constructs?
foo.length++;
++foo.length;
foo.length += 42;

For the first two I can see that refusing them would encourage the use of ~= to append to arrays, as in 9 of 10 cases the next line is probably an assignment of the last element.

But for the last one, I kind of guess that making one huge resize and then adding the elements can be fore effective (Unless the elements to add are in an array as well).

And does this have anything to do with this construct not working:
class Foo {
  private int _bar = 2;
  void bar(int newbar) { _bar = newbar; }
  int bar() { return _bar; }
}
int main(char[][] args) {
  Foo foo = new Foo;
  foo.bar++;		// Not a scalar
  ++foo.bar;		// --"--
  foo.bar += 1;		// --"--
  foo.bar = foo.bar + 1; // Well this works :)
  return 0;
}

I was under the impression that 'a+=1' was simply rewritten as 'a=a+1', but then I have never written a complete compiler myself :) (Only dabbled with a LISP interpreter).

regards
	Fredrik Olsson
August 23, 2005
Fredrik Olsson <peylow@gmail.com> wrote in news:deeh6r$2esr$1@digitaldaemon.com

> Is there a technical problem that hinders these constructs?
[...]

From the specs:
| Note: Properties currently cannot be the lvalue of an op=, ++, or
-- operator.

-manfred
August 23, 2005
Manfred Nowak skrev:
> Fredrik Olsson <peylow@gmail.com> wrote in
> news:deeh6r$2esr$1@digitaldaemon.com 
> 
> 
>>Is there a technical problem that hinders these constructs?
> 
> [...]
> 
> From the specs:
> | Note: Properties currently cannot be the lvalue of an op=, ++, or -- operator.
> 
So I have read, no problem with that, if I had I would have posted under bugs :). I am more curious as to why this limitation has survived for so long. As I believe it may be a feature quite frequently asked for, and I read that at least ++foo is rewritten as foo += 1, so I assumed a further rewrite to foo = foo + 1, but I guess I was wrong on that account.

So I was just curious if it is left because of philosophical reasons (such as encouraging ~=), or if there is a technical obstacle. Or perhaps no one have even thought of it before? ;)

regards
	Fredrik Olsson
August 23, 2005
On Tue, 23 Aug 2005 08:54:07 +0200, Fredrik Olsson wrote:

> Is there a technical problem that hinders these constructs?
> foo.length++;
> ++foo.length;
> foo.length += 42;
> 
> For the first two I can see that refusing them would encourage the use of ~= to append to arrays, as in 9 of 10 cases the next line is probably an assignment of the last element.
> 
> But for the last one, I kind of guess that making one huge resize and then adding the elements can be fore effective (Unless the elements to add are in an array as well).
> 
> And does this have anything to do with this construct not working:
> class Foo {
>    private int _bar = 2;
>    void bar(int newbar) { _bar = newbar; }
>    int bar() { return _bar; }
> }
> int main(char[][] args) {
>    Foo foo = new Foo;
>    foo.bar++;		// Not a scalar
>    ++foo.bar;		// --"--
>    foo.bar += 1;		// --"--
>    foo.bar = foo.bar + 1; // Well this works :)
>    return 0;
> }

Yes, this is the reason that array.length can't be used as an lvalue. The length of an array is implemented as a 'property' which means that its a function call rather than a direct access of some RAM. So in effect

  array.length++;

would be equivalent to

  array.length()++;

which is not what you really want.

If you look at your example

   int X = foo.bar;
   foo.bar = 2;

is the same as

   int X = foo.bar();
   foo.bar(2);

and this means that 'foo.bar++' is the same as 'foo.bar()++' which is
meaningless code (disregarding any side effects).

 foo.bar = foo.bar + 1;

is the same as

  foo.bar( foo.bar + 1);

Hope this helps.

> I was under the impression that 'a+=1' was simply rewritten as 'a=a+1', but then I have never written a complete compiler myself :) (Only dabbled with a LISP interpreter).

Unfortunately this is not the case with 'properties'. I hope that one day Walter can transparently get the compiler to recognize properties and really treat them as if they were member variables. It would make writing generic code a lot simpler.

-- 
Derek Parnell
Melbourne, Australia
24/08/2005 1:20:31 AM