• John C <johnch_atms hotmail.com> Jul 27 2009

John C <johnch_atms hotmail.com> writes:

Steven Schveighoffer Wrote:

 On Mon, 27 Jul 2009 12:16:59 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 That's why properties are not
 functions.


 This post had a negative effect on me: I now think properties are  
 functions even more than before.


  writefln = "hi";
  :)


 That wart must be eliminated. But the shortcomings of the current design  
 are not a proof that we need a specialized facility for what is at the  
 end of the day nothing but a notational convenience.


 I personally am OK with any solution that allows me to specify that a  
 function is actually a property, thereby restricting the compiler from  
 allowing assignment calls with normal functions.
 
 The most straightforward solution I can think of is marking a function  
 with a keyword, i.e.:
 
 property int x() {return _x;}
 property void x(int n) {_x = n;}


Agreed. And enabling the function pair to be enclosed in a block would reduce
repitition a tad as well as indicate they are one entity.

property {
  int x() { return _x; }
  void x(int n) { _x = n; }
}

 
 The other syntax suggestions provide different added bonuses, but I think  
 all of those bonuses are not as critical as code working as expected.
 
 For example:
 
 - implied hidden storage
 - documenting property getters/setters as one entity
 - being able to execute a getter during a debug session.
 
 -Steve