www.digitalmars.com         C & C++   DMDScript  

D - settors/gettors bad idea

reply Edward Lam <Edward_member pathlink.com> writes:
Hi,

I'm new to D and looking at the spec, I hate the idea of the gettors/settors
property. Has anyone ever tried maintaining a large code base with this idea? I
have! I currently work at a company that has accessors written similar this in
C++ everywhere:

class FOO {
public:
int property() const { return myProperty; }
int &property()      { return myProperty; }
private:
int myProperty;
};

This effectively lets you do stuff like this:
FOO f;
int i = f.property();
f.property() = i;

It is absolutely hell to trace through code like this in a large codebase when
you want to find where a member variable is ever used but not assigned. This is
often done in sweeps to ensure that a particular property is used properly or to
find out how it is used.

In this type of system, the only way to search for this is to look for the
pattern "property()". However, good luck trying to find what you want if there's
a like a 1000 references that use the property but only a few cases where it is
ever externally assigned. It is a huge pain. The problem compounds itself when
you have to look for a common property name. Even if you were just trying to
find all instances for when the property is assigned requires doing a grep for
"\<property()[ \t]*=\>" and that's when you remember how to do it properly. At
least with get/set methods you can grep for getProperty() and setProperty()
separately and easily. 

I really hope the designers of D reconsider this aspect of the language.

Regards,
-Edward
Jan 12 2003
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Edward Lam wrote:

 I'm new to D and looking at the spec, I hate the idea of the gettors/settors
 property. Has anyone ever tried maintaining a large code base with this idea? I
 have! I currently work at a company that has accessors written similar this in
 C++ everywhere:
 
 class FOO {
 public:
 int property() const { return myProperty; }
 int &property()      { return myProperty; }
 private:
 int myProperty;
 };
 
 This effectively lets you do stuff like this:
 FOO f;
 int i = f.property();
 f.property() = i;
 
 It is absolutely hell to trace through code like this in a large codebase when
 you want to find where a member variable is ever used but not assigned. This is
 often done in sweeps to ensure that a particular property is used properly or
to
 find out how it is used.


If you use MSVC, how do the source browsing utilities fail you here?  If 
not MSVC, how could an IDE help automate this search?
Jan 12 2003
prev sibling next sibling parent Niall Douglas <Niall_member pathlink.com> writes:
In article <avs69v$2pt8$1 digitaldaemon.com>, Edward Lam says...


 I currently work at a company that has accessors written similar this in
C++ everywhere:

class FOO {
public:
int property() const { return myProperty; }
int &property()      { return myProperty; }
private:
int myProperty;
};

This effectively lets you do stuff like this:
FOO f;
int i = f.property();
f.property() = i;


I don't actually agree with OO, but <Niall shudders violently>


It is absolutely hell to trace through code like this in a large codebase when
you want to find where a member variable is ever used but not assigned. This is
often done in sweeps to ensure that a particular property is used properly or to
find out how it is used.


Good god ...


 At
least with get/set methods you can grep for getProperty() and setProperty()
separately and easily. 

I really hope the designers of D reconsider this aspect of the language.


I think it's better form to use .attribute() for read-only and .setAttribute()
for writing. If you do like your company and return a writeable reference, you
might as well just make the variable public will all the nastiness you
mentioned. BTW, good C++ sets ALL variables in a class to zero in its
constructor - you can always remove them later if speed is an issue.

My own view on properties is that yes, they are absolutely needed - for class
designers and dynamically loaded libraries especially. However, I'd add the
following idiom:

class X
{
public:
int foo;
};

a=X.foo(); // Read
X.foo()=5; // Error: idiom is not for writing!
X.foo=5;   // Still works, but should never be used except in 0.001% of cases

My reasoning for this is often I have to do the following in my C++:

class Y
{
int myfoo;
public:
int foo() const { return myfoo; }
// Optional Y &setFoo(int a) { myfoo=a; return *this; }
};

In other words, I want variable access via a method so I can replace it with
something more complex later without breaking anything. However, to make good
C++ I am forced to write lots of extra code (C++'s major failing IMHO) such as
prefixing all my "properties" with "my" so they don't conflict with the read
method.

My suggested idiom won't break any existing code and shortcuts the process
nicely. I'm opposed to having .getFoo() simply because (a) more typing (b) looks
ugly (c) isn't intuitively OO (properties of a real life object are a given ie;
immediately obvious - you don't "get" them. You do however set them).

Cheers,
Niall
Jan 12 2003
prev sibling parent reply factory <tehdasX optushome.com.au> writes:
In article <avs69v$2pt8$1 digitaldaemon.com>, Edward_member pathlink.com 
says...

 I'm new to D and looking at the spec, I hate the idea of the gettors/settors
 property. Has anyone ever tried maintaining a large code base with this idea? I
 have! I currently work at a company that has accessors written similar this in
 C++ everywhere:
 
 class FOO {
 public:
 int property() const { return myProperty; }
 int &property()      { return myProperty; }
 private:
 int myProperty;
 };
 
 This effectively lets you do stuff like this:
 FOO f;
 int i = f.property();
 f.property() = i;
 


...

 I really hope the designers of D reconsider this aspect of the language.


  Personally I would say that doing it somewhat similarly to how MSVC 
does it: 

struct A
{
	int GetA() { return a; }	
	int PutA( int newA ) { a= newA; }	

	int a;

	__declspec( property( get=GetA, put=PutA ) )
		int a;
};

so: 
  A a;

  a.a= 2; // calls PutA( 2 )

  cout << a.a;  // calls GetA()

Microsofts implementation is nice for the users of the class, but 
somewhat cumbersome for the designers of the class. 

Perhaps a better way is:

struct A
{
	gettor( a ) int GetA() { return a; }	
	settor( a ) int PutA( int newA ) { a= newA; }	

	int a;
};

or even:

struct A
{
	int GetA() { return a; }	
	int PutA( int newA ) { a= newA; }	

	settor( PutA ) gettor( GetA ) int a;
	// access( PutA, GetA ) int a; ??
};

  - Factory
Jan 14 2003
parent reply Paul Stanton <Paul_member pathlink.com> writes:
not sure why any of this needs to be done automatic anyway. y not just (like
java does) leave it all to be explicitly defined by programmer?
Jan 16 2003
parent reply Andy Friesen <andy ikagames.com> writes:
It's a simple matter of readability.  Getters/setters look a lot nicer 
than get/set methods.  Which do you prefer:

	window.SetWidth(window.GetWidth() + 10)
or
	window.Width += 10;

Another example is a rectangle struct that exposes x, y, width, height, 
top, left, bottom, and right properties all at once, and allows all to 
be read or written as suits the situation at hand.

There's also nice (though arguably naughty) tricks like making a 
variable public, then later wrapping it up into a getter/setter when it 
becomes necessary, without changing the public interface.

You do have a point; getter/setters are just syntactic sugar.  But 
they're kind of sugar that helps make a lot of things simpler and more 
intuitive, and just a Very Good Thing to have in general.

Paul Stanton wrote:

 not sure why any of this needs to be done automatic anyway. y not just (like
 java does) leave it all to be explicitly defined by programmer?
Jan 16 2003
parent reply Paul Stanton <Paul_member pathlink.com> writes:
yeah, i c ur point.

but personally, i would take the hit for the following reason...
By nature, getters and setters dont have to be simple getters and setters. they
can (some cases should not) contain logic. therefore, i would want it explicit
that i was using programmer defined methods ("x.setY(x.getY()+10)"), rather then
an operator ("x.y+=10").

In article <b07ndv$24tn$1 digitaldaemon.com>, Andy Friesen says...

It's a simple matter of readability.  Getters/setters look a lot nicer 
than get/set methods.  Which do you prefer:

	window.SetWidth(window.GetWidth() + 10)
or
	window.Width += 10;

Another example is a rectangle struct that exposes x, y, width, height, 
top, left, bottom, and right properties all at once, and allows all to 
be read or written as suits the situation at hand.

There's also nice (though arguably naughty) tricks like making a 
variable public, then later wrapping it up into a getter/setter when it 
becomes necessary, without changing the public interface.

You do have a point; getter/setters are just syntactic sugar.  But 
they're kind of sugar that helps make a lot of things simpler and more 
intuitive, and just a Very Good Thing to have in general.

Paul Stanton wrote:

 not sure why any of this needs to be done automatic anyway. y not just (like
 java does) leave it all to be explicitly defined by programmer?
Jan 16 2003
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
If you want to be *really* explicit, you can use assembly. ;)  I prefer 
to abstract things when it makes life easier.


as assign values is the whole point.  Checking bounds, or relaying to an 
external API along with an assignment is a useful idiom that, like 
anything, can be misused.  It's just a matter of whether it's easy 
enough to use properly, and worth the potential for "evil."

In the case of properties, I would say that they're well worth it.

Paul Stanton wrote:

 yeah, i c ur point.
 
 but personally, i would take the hit for the following reason...
 By nature, getters and setters dont have to be simple getters and setters. they
 can (some cases should not) contain logic. therefore, i would want it explicit
 that i was using programmer defined methods ("x.setY(x.getY()+10)"), rather
then
 an operator ("x.y+=10").
 
 In article <b07ndv$24tn$1 digitaldaemon.com>, Andy Friesen says...
 

It's a simple matter of readability.  Getters/setters look a lot nicer 
than get/set methods.  Which do you prefer:

	window.SetWidth(window.GetWidth() + 10)
or
	window.Width += 10;

Another example is a rectangle struct that exposes x, y, width, height, 
top, left, bottom, and right properties all at once, and allows all to 
be read or written as suits the situation at hand.

There's also nice (though arguably naughty) tricks like making a 
variable public, then later wrapping it up into a getter/setter when it 
becomes necessary, without changing the public interface.

You do have a point; getter/setters are just syntactic sugar.  But 
they're kind of sugar that helps make a lot of things simpler and more 
intuitive, and just a Very Good Thing to have in general.

Paul Stanton wrote:


not sure why any of this needs to be done automatic anyway. y not just (like
java does) leave it all to be explicitly defined by programmer?
Jan 16 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Andy Friesen" <andy ikagames.com> escreveu na mensagem
news:b07pab$25t5$1 digitaldaemon.com...

 If you want to be *really* explicit, you can use assembly. ;)  I prefer
 to abstract things when it makes life easier.


 as assign values is the whole point.  Checking bounds, or relaying to an
 external API along with an assignment is a useful idiom that, like
 anything, can be misused.  It's just a matter of whether it's easy
 enough to use properly, and worth the potential for "evil."

 In the case of properties, I would say that they're well worth it.

 Paul Stanton wrote:

 yeah, i c ur point.

 but personally, i would take the hit for the following reason...
 By nature, getters and setters dont have to be simple getters and




setters. they

 can (some cases should not) contain logic. therefore, i would want it




explicit

 that i was using programmer defined methods ("x.setY(x.getY()+10)"),




rather then

 an operator ("x.y+=10").

 In article <b07ndv$24tn$1 digitaldaemon.com>, Andy Friesen says...


It's a simple matter of readability.  Getters/setters look a lot nicer
than get/set methods.  Which do you prefer:

 window.SetWidth(window.GetWidth() + 10)
or
 window.Width += 10;

Another example is a rectangle struct that exposes x, y, width, height,
top, left, bottom, and right properties all at once, and allows all to
be read or written as suits the situation at hand.

There's also nice (though arguably naughty) tricks like making a
variable public, then later wrapping it up into a getter/setter when it
becomes necessary, without changing the public interface.

You do have a point; getter/setters are just syntactic sugar.  But
they're kind of sugar that helps make a lot of things simpler and more
intuitive, and just a Very Good Thing to have in general.

Paul Stanton wrote:


not sure why any of this needs to be done automatic anyway. y not just








(like

java does) leave it all to be explicitly defined by programmer?








Hi,

    Dumb data-holders with properties are quick to develop, but awful in
good OO design. This kind of programming leads to proliferation of data
objects and controller objects, as in most GUI APIs available today. Sure
window.width += 10 is better than window.setWidth(window.getWidth() + 10),
but what we're looking for are method to say. window.increaseBy(0, 10) or
something like that.

    Best regards,
    Daniel Yokomiso.

"Life may have no meaning. Or even worse, it may have a meaning of which I
disapprove."
- Ashleigh Brilliant"Andy Friesen" <andy ikagames.com> escreveu na mensagem
news:b07pab$25t5$1 digitaldaemon.com...

 If you want to be *really* explicit, you can use assembly. ;)  I prefer
 to abstract things when it makes life easier.


 as assign values is the whole point.  Checking bounds, or relaying to an
 external API along with an assignment is a useful idiom that, like
 anything, can be misused.  It's just a matter of whether it's easy
 enough to use properly, and worth the potential for "evil."

 In the case of properties, I would say that they're well worth it.

 Paul Stanton wrote:

 yeah, i c ur point.

 but personally, i would take the hit for the following reason...
 By nature, getters and setters dont have to be simple getters and




setters. they

 can (some cases should not) contain logic. therefore, i would want it




explicit

 that i was using programmer defined methods ("x.setY(x.getY()+10)"),




rather then

 an operator ("x.y+=10").

 In article <b07ndv$24tn$1 digitaldaemon.com>, Andy Friesen says...


It's a simple matter of readability.  Getters/setters look a lot nicer
than get/set methods.  Which do you prefer:

 window.SetWidth(window.GetWidth() + 10)
or
 window.Width += 10;

Another example is a rectangle struct that exposes x, y, width, height,
top, left, bottom, and right properties all at once, and allows all to
be read or written as suits the situation at hand.

There's also nice (though arguably naughty) tricks like making a
variable public, then later wrapping it up into a getter/setter when it
becomes necessary, without changing the public interface.

You do have a point; getter/setters are just syntactic sugar.  But
they're kind of sugar that helps make a lot of things simpler and more
intuitive, and just a Very Good Thing to have in general.

Paul Stanton wrote:


not sure why any of this needs to be done automatic anyway. y not just








(like

java does) leave it all to be explicitly defined by programmer?








Hi,

    Dumb data-holders with properties are quick to develop, but awful in
good OO design. This kind of programming leads to proliferation of data
objects and controller objects, as in most GUI APIs available today. Sure
window.width += 10 is better than window.setWidth(window.getWidth() + 10),
but what we're looking for are method to say. window.increaseBy(0, 10) or
something like that.

    Best regards,
    Daniel Yokomiso.

"Life may have no meaning. Or even worse, it may have a meaning of which I
disapprove."
- Ashleigh Brilliant
Jan 17 2003
prev sibling next sibling parent reply Jonathan Andrew <Jonathan_member pathlink.com> writes:
In article <b07oae$25bl$1 digitaldaemon.com>, Paul Stanton says...

yeah, i c ur point.

but personally, i would take the hit for the following reason...
By nature, getters and setters dont have to be simple getters and setters. they
can (some cases should not) contain logic. therefore, i would want it explicit
that i was using programmer defined methods ("x.setY(x.getY()+10)"), rather then
an operator ("x.y+=10").


Maybe as a matter of style, the programmer should capitalize the first letter
of the property to distinguish it from regular public variables. Perhaps
that should go in the style guide. (Once properties are implemented.)


In article <b07ndv$24tn$1 digitaldaemon.com>, Andy Friesen says...

It's a simple matter of readability.  Getters/setters look a lot nicer 
than get/set methods.  Which do you prefer:

	window.SetWidth(window.GetWidth() + 10)
or
	window.Width += 10;

Another example is a rectangle struct that exposes x, y, width, height, 
top, left, bottom, and right properties all at once, and allows all to 
be read or written as suits the situation at hand.

There's also nice (though arguably naughty) tricks like making a 
variable public, then later wrapping it up into a getter/setter when it 
becomes necessary, without changing the public interface.

You do have a point; getter/setters are just syntactic sugar.  But 
they're kind of sugar that helps make a lot of things simpler and more 
intuitive, and just a Very Good Thing to have in general.

Paul Stanton wrote:

 not sure why any of this needs to be done automatic anyway. y not just (like
 java does) leave it all to be explicitly defined by programmer?
Jan 16 2003
parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
I think the point of properties is to make them look and feel just like
variables.  Templates can leverage this.

One of the things I don't like about Sather is all the rules about how you
have to capitalize the identifiers.  I'd much rather the language be case
agnostic.

Sean

"Jonathan Andrew" <Jonathan_member pathlink.com> wrote in message
news:b0873a$2ct0$1 digitaldaemon.com...

 Maybe as a matter of style, the programmer should capitalize the first


letter

 of the property to distinguish it from regular public variables. Perhaps
 that should go in the style guide. (Once properties are implemented.)
Jan 17 2003
prev sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
Why does everything have to be so damned explicit?!!

And how is "x.setY(x.getY()+10)" any more understandable than "x.y+=10"??

The problem here is your preconceived notions of what programming is about.
I for one do not want to be forced to be explicit about every little detail
of execution.  Taken to the extreme that would eliminate *ALL* code reuse.

I *LIKE* the idea of the compiler understanding something more similar to my
native language, instead of forcing me to use its alien computer tongue.

D has an opportunity here to "rewrite the rules" so to speak.  I'd carefully
consider any artificial limitations.

Sean

"Paul Stanton" <Paul_member pathlink.com> wrote in message
news:b07oae$25bl$1 digitaldaemon.com...

 yeah, i c ur point.

 but personally, i would take the hit for the following reason...
 By nature, getters and setters dont have to be simple getters and setters.


they

 can (some cases should not) contain logic. therefore, i would want it


explicit

 that i was using programmer defined methods ("x.setY(x.getY()+10)"),


rather then

 an operator ("x.y+=10").
Jan 17 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b08h6l$2isd$1 digitaldaemon.com...

 Why does everything have to be so damned explicit?!!

 And how is "x.setY(x.getY()+10)" any more understandable than "x.y+=10"??


it depends what x is; to me

"x.y+=10" => or x.y.incBy( 10 )

operator += rather than set with get op+ 10
Jan 17 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
So write x.y = x.y + 10 then.  Still better than get and set with all the
parenthesis.

Sean

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:b08rp1$2nqf$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b08h6l$2isd$1 digitaldaemon.com...

 Why does everything have to be so damned explicit?!!

 And how is "x.setY(x.getY()+10)" any more understandable than




"x.y+=10"??


 it depends what x is; to me

 "x.y+=10" => or x.y.incBy( 10 )

 operator += rather than set with get op+ 10





 Jan 17 2003



  parent  "Mike Wynn" <mike.wynn l8night.co.uk>  writes:


"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b09jo3$60l$1 digitaldaemon.com...

 So write x.y = x.y + 10 then.  Still better than get and set with all the
 parenthesis.


agree, I was answering the question

 And how is "x.setY(x.getY()+10)" any more understandable than
 "x.y+=10"??







and it depends on your view of what D is; if D is a replacement to C/C++ and
other algo60 derived langs which should be more powerful than any that have
come before then allowing x.y += 10; to be x.y = x.y + 10 which is
x.y.set( x.y.get().add( 10 ) );
as long as its in the docs, then fine;


power of C but with less pitfalls for the unwary and better compile checks
and more builtin feature to ease programming at the expence of some features
which would require the programmer knowing about the inner workings of the
compiler and its behaviour in given situations. then I say operator
overloading is a bad feature so += would not be allowed anyway
gettors/settors are not a bad feature as they ease the code effectivly the
only overloaded operator is '='

as with all these features we all have a different view, I for instance
dislike builtin hashtables/assoc arrays and think
that they should be a templated class which has an indexed getor/setor (like
indexed props in delphi)
template map(F, T) {
    class hashtable {
        get T this[F key] { .... }
        set  this[F key](T value ) { ... }
    }
    // other types of map ... etc
    class searchablesortedbinarytree {
    }
}
so instead of
    int[char*] foo;
you'd use something like
    instance map( char *, int ).hashtable foo;

and I'd like virtual static and virtual constructor from delphi too;
    so to create foo would be
    foo.new( params );  (like eiffel I believe operator !! );
    not
    instance map( char *, int ).hashtable foo = new instance map( char *,
int ).hashtable( params );

 "Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
 news:b08rp1$2nqf$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b08h6l$2isd$1 digitaldaemon.com...

 Why does everything have to be so damned explicit?!!

 And how is "x.setY(x.getY()+10)" any more understandable than




 "x.y+=10"??


 it depends what x is; to me

 "x.y+=10" => or x.y.incBy( 10 )

 operator += rather than set with get op+ 10







 Jan 17 2003



prev sibling  parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org>  writes:


Sean L. Palmer wrote:

 Why does everything have to be so damned explicit?!!
 
 And how is "x.setY(x.getY()+10)" any more understandable than "x.y+=10"??
 
 The problem here is your preconceived notions of what programming is about.
 I for one do not want to be forced to be explicit about every little detail
 of execution.  Taken to the extreme that would eliminate *ALL* code reuse.
 
 I *LIKE* the idea of the compiler understanding something more similar to my
 native language, instead of forcing me to use its alien computer tongue.
 
 D has an opportunity here to "rewrite the rules" so to speak.  I'd carefully
 consider any artificial limitations.


Amen!

If you want, you can always write a code style document for your 
organization that bans such use of properties.  But if they aren't in 
the language, then NOBODY can use them, not even those who want to.



I'm in favor of allowing syntax sugar provided that it meets three 
requirements:
	* doesn't forbid using the low-level "old" style (for
	  performance or other reasons)
	* doesn't add overhead to all programs
	  even those that don't use the feature
	* doesn't make the compiler markedly harder to write



The truth is, if your properties are working sanely, then
	x.y += 10;
is VERY readable to the casual programmer.  The people who care about 
performance are the ones who will know the internals of the language and 
the compiler, and they will be intimately aware of the complexity hidden 
in that simple statement.  So why is this an pitfall-prone feature?



 Jan 21 2003



  parent reply Antti Sykari <jsykari gamma.hut.fi>  writes:


Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:

 	x.y += 10;

 is VERY readable to the casual programmer.  The people who care about
 performance are the ones who will know the internals of the language
 and the compiler, and they will be intimately aware of the complexity
 hidden in that simple statement.  So why is this an pitfall-prone
 feature?


By the way -- assuming there are some people who know the internals of
the language in this newsgroup ;) -- what does "x.y += 10" mean?

By looking at it (by following the D documentation in "Operator
overloading") calls the method (or member function) addass(10); on the
value returned by x.y();

However, the effects of that call depend on whether y is an integral
or struct type or a reference type, such as a class.  If it's a class,
x.y() returns a reference to the object; but if it's, for example, an
integer, x.y() returns a copy of it.  And in this case a "+= 10" is
performed on a temporary value.

What actually _should_ happen is not to call .addass() but to first
transform "x.y += 10" into "x.y = x.y + 10" (actually that is not
enough but more on that later), which leads into calling of the
gettor, followed by calling of the settor.

Am I wrong?  Or is this a problem?

-Antti



 Jan 22 2003



  parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org>  writes:


Antti Sykari wrote:

 Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
 

	x.y += 10;

is VERY readable to the casual programmer.  The people who care about
performance are the ones who will know the internals of the language
and the compiler, and they will be intimately aware of the complexity
hidden in that simple statement.  So why is this an pitfall-prone
feature?


 
 
 By the way -- assuming there are some people who know the internals of
 the language in this newsgroup ;) -- what does "x.y += 10" mean?
 
 By looking at it (by following the D documentation in "Operator
 overloading") calls the method (or member function) addass(10); on the
 value returned by x.y();
 
 However, the effects of that call depend on whether y is an integral
 or struct type or a reference type, such as a class.  If it's a class,
 x.y() returns a reference to the object; but if it's, for example, an
 integer, x.y() returns a copy of it.  And in this case a "+= 10" is
 performed on a temporary value.
 
 What actually _should_ happen is not to call .addass() but to first
 transform "x.y += 10" into "x.y = x.y + 10" (actually that is not
 enough but more on that later), which leads into calling of the
 gettor, followed by calling of the settor.
 
 Am I wrong?  Or is this a problem?
 
 -Antti


I don't know if there is a spec yet.  In fact, I don't know that the += 
operator even works for gettors & settors yet.  My point, though, is 
that if and when that is implemented, the low-level performance freaks 
will certainly know what the spec is and how best to use it.

Personally, I think that yes,
	x.y += 10;
should expand to
	x.y = x.y + 10;
which would result in a call to the gettor, an add, and a call to the 
settor.



 Jan 22 2003



  parent  "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br>  writes:


"Russell Lewis" <spamhole-2001-07-16 deming-os.org> escreveu na mensagem
news:3E2EE2EF.4030109 deming-os.org...

 Antti Sykari wrote:

 Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:


 x.y += 10;

is VERY readable to the casual programmer.  The people who care about
performance are the ones who will know the internals of the language
and the compiler, and they will be intimately aware of the complexity
hidden in that simple statement.  So why is this an pitfall-prone
feature?



 By the way -- assuming there are some people who know the internals of
 the language in this newsgroup ;) -- what does "x.y += 10" mean?

 By looking at it (by following the D documentation in "Operator
 overloading") calls the method (or member function) addass(10); on the
 value returned by x.y();

 However, the effects of that call depend on whether y is an integral
 or struct type or a reference type, such as a class.  If it's a class,
 x.y() returns a reference to the object; but if it's, for example, an
 integer, x.y() returns a copy of it.  And in this case a "+= 10" is
 performed on a temporary value.

 What actually _should_ happen is not to call .addass() but to first
 transform "x.y += 10" into "x.y = x.y + 10" (actually that is not
 enough but more on that later), which leads into calling of the
 gettor, followed by calling of the settor.

 Am I wrong?  Or is this a problem?

 -Antti


 I don't know if there is a spec yet.  In fact, I don't know that the +=
 operator even works for gettors & settors yet.  My point, though, is
 that if and when that is implemented, the low-level performance freaks
 will certainly know what the spec is and how best to use it.

 Personally, I think that yes,
 x.y += 10;
 should expand to
 x.y = x.y + 10;
 which would result in a call to the gettor, an add, and a call to the
 settor.


"x.y += 10" is defined to call addass on whatever "x.y" gives to you. If its
a primitive, like int, it'll check first if x.y is a valid lvalue, if not
give a compiler error AFAIK. addass is targeted for performance reasons, so
two 100 x 100 Matrices can be added without generating any temporary
garbage. Anything different from that will require some kind of template
expressions to be efficient. But this is only valid for "A += B". If you
write "A += B + C + D"; you'll get intermediate garbage anyway.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003



 Jan 22 2003