Properties

[Don]

dsimcha wrote:
> == Quote from BCS (ao at 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.