dsimcha wrote:
== Quote from BCS (a...@pathlink.com)'s article
Reply to Vishaal,
Properties, such as array.length, should return lvalues to allow:
a.length += 8;
or other similar statements.
I think there is a (long standing) bug report about that one. Maybe if enough
people gripe about it it will get fixed! (NOT said sarcastically!)
Yeah, this has been mentioned in the past before. The most obvious way to make
it
work w/o any breaking or significantly bulk-adding changes would be to define
foo.length += 8 to mean foo = foo.length() + 8, or foo.length++ mean foo =
foo.length + 1. This would be pure syntactic sugar, as it is when working with
primitives.
One problem that comes to mind is if, instead of length, which is presumably
some
kind of integer, you have a property for some user defined type with operator
overloading. This user-defined type could define opAdd to do something
arbitrarily different from opAddAssign. Even if we assume that no reasonable
programmer would do this and treat this as a "who cares?" corner case,
It was recently pointed out in another thread that if prop is a class,
it is currently nearly IMPOSSIBLE for prop += 8; to be the same as prop
= prop + 8;.
Properties therefore seem to be another important reason for fixing up
operator overloading.
there's
still the problem of opInc and opAddAssign being much cheaper in some cases than
opAdd. For example, in some cases opAdd might require copying of a whole bunch
of
stuff, where opInc or opAddAssign just increments a single primitive under the
hood.
Bottom line is, unless we assume that properties of user-defined types aren't
important, we need a better solution. Oh yeah, and on the more special case of
arrays, which the compiler already treats as special, yes, foo.length += 2
should
be legal. As far as I can tell, this is a no-brainer.
