View mode: basic / threaded / horizontal-split · Log in · Help
January 08, 2009
Properties
Properties, such as array.length, should return lvalues to allow:
a.length += 8;
or other similar statements.
January 08, 2009
Re: Properties
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!)
January 08, 2009
Re: Properties
On Thu, 08 Jan 2009 00:49:38 +0000, BCS wrote:

> 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!)

http://d.puremagic.com/issues/show_bug.cgi?id=808

*gripes*
January 08, 2009
Re: Properties
== Quote from BCS (ao@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, 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.
January 08, 2009
Re: Properties
BCS wrote:
> 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!)
> 
> 

Gripe gripe gripe gripe gripe
January 08, 2009
Re: Properties
dsimcha Wrote:

> == Quote from BCS (ao@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, 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.

The two methods aren't mutually exclusive. We could let users write opAddAssign if they want but if there would be no benefit (or if they don't care about memory) they wouldn't have to write an opAddAssign and the compiler would expand it.
++gripes.length;

Sorry, gripes.length = gripes.length + 1;
January 08, 2009
Re: Properties
Ellery Newcomer wrote:
> BCS wrote:
>> 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!)
>>
>>
> 
> Gripe gripe gripe gripe gripe

Guriiiiipe. Gripe gripe. GRIPE.
January 08, 2009
Re: Properties
Alexander Pánek:
> Guriiiiipe. Gripe gripe. GRIPE.

Is this the second (redundant) system to vote for the most hated bugs?

Bye,
bearophile
January 08, 2009
Re: Properties
bearophile wrote:
> Alexander Pánek:
>> Guriiiiipe. Gripe gripe. GRIPE.
> 
> Is this the second (redundant) system to vote for the most hated bugs?
> 
> Bye,
> bearophile

Maybe we need a bot to monitor bugs' GPS [1].  You can never have too 
many redundant systems, afterall!

 -- Daniel

P.S. Gripe gripe, gr-gr-gripe, GRIPE!

[1] Gripes Per Second.
January 08, 2009
Re: Properties
dsimcha wrote:

> 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, 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.

I've always thought properties should work somewhat like this:

property int length {
   get() { return this.len; }
   set(newLen) { this.len = newLen; }
}

The return-type of get is automatically int, as is the parameter-type of
set. These two functions are automatically called when the property is
used.

int a = length;
// int a = length.get();

length = 10;
// length.set(10);

In cases where read/write access is needed, the compiler can do this:

length++;
// int temp = length.get();
// temp++;
// length.set(temp);

This can work for any user-defined type, since we're using the same
operator. If you want it done faster 'under the hood', you can use
operator-overloads inside the property:

property int length {
   get() { return this.len; }
   set(newLen) { this.len = newLen; }
   void opIncrement() { this.len++; }
}

-- 
Michiel
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home