www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - properties - Why not the set/get syntax?

reply Cris <central_p hotmail.com> writes:
Why the properties in D do not use the set/get syntax? It looks more clear and 
natural to me.
Apr 01 2006
next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Cris" <central_p hotmail.com> wrote in message 
news:e0lg9c$27q4$1 digitaldaemon.com...
 Why the properties in D do not use the set/get syntax? It looks more clear 
 and natural to me.

Which syntax? There are many. C#, VB, Delphi, C++/CLI, Visual C++ ... take your pick. (But none exists for Java - purists would tell you it's just so very wrong.) This comes up every few months. So that we don't rehash the same arguments, here's the previous thread on this topic: http://www.digitalmars.com/d/archives/digitalmars/D/31802.html John C.
Apr 01 2006
parent reply Cris <central_p hotmail.com> writes:
How would you implement a  write only property?

So if you want ot have a read and write property you just have to add one read
and 
one write property?

 struct Foo
 {
     int data() { return m_data; }	// read property
 
     int data(int value) { return m_data = value; } // write property
 
   private:
     int m_data;
 }

C#'s syntax feels a little bit more clear to me. I'm reading now the link you've posted before.
Apr 01 2006
parent reply "John C" <johnch_atms hotmail.com> writes:
"Cris" <central_p hotmail.com> wrote in message 
news:e0lr0p$2n17$1 digitaldaemon.com...
 How would you implement a  write only property?

Implement only the setter.
 So if you want ot have a read and write property you just have to add one 
 read and one write property?

Correct.
 struct Foo
 {
     int data() { return m_data; } // read property

     int data(int value) { return m_data = value; } // write property

   private:
     int m_data;
 }

C#'s syntax feels a little bit more clear to me. I'm reading now the link you've posted before.

I agree it's a lot nicer. But many think it's too verbose. I'd be willing to sacrifice succinctness for clarity.
Apr 01 2006
parent reply Cris <central_p hotmail.com> writes:
John C wrote:
 "Cris" <central_p hotmail.com> wrote in message 
 news:e0lr0p$2n17$1 digitaldaemon.com...
 How would you implement a  write only property?

Implement only the setter.

I mean a property that you can write but you cannot read. You can do that in C#. Is it possible in D too?
Apr 01 2006
next sibling parent reply Cris <central_p hotmail.com> writes:
Cris wrote:
 John C wrote:
 "Cris" <central_p hotmail.com> wrote in message 
 news:e0lr0p$2n17$1 digitaldaemon.com...
 How would you implement a  write only property?

Implement only the setter.

I mean a property that you can write but you cannot read. You can do that in C#. Is it possible in D too?

Oh, yes it's possible: class Bicycle { this() { gear = 1; } int currentGear; int gear() { return currentGear; } void gear(int value) { currentGear = value; } } So it means that there is absolyutely no difference between properties and functions in D? Perhaps the notion "property" is a little bit confusing in this case.
Apr 01 2006
parent reply "John C" <johnch_atms hotmail.com> writes:
"Cris" <central_p hotmail.com> wrote in message 
news:e0m0lc$2slj$1 digitaldaemon.com...
 Cris wrote:
 John C wrote:
 "Cris" <central_p hotmail.com> wrote in message 
 news:e0lr0p$2n17$1 digitaldaemon.com...
 How would you implement a  write only property?

Implement only the setter.

I mean a property that you can write but you cannot read. You can do that in C#. Is it possible in D too?

Oh, yes it's possible: class Bicycle { this() { gear = 1; } int currentGear; int gear() { return currentGear; } void gear(int value) { currentGear = value; } }

But Bicycle.gear can be both read and written. I showed you in another reply how to do a write-only property.
 So it means that there is absolyutely no difference between properties and 
 functions in D? Perhaps the notion "property" is a little bit confusing in 
 this case.

This is why people keep suggesting an alternative syntax so that the compiler distinguishes between them. But it works most of the time, unless you're using it with auto type inference (in which case you need to use the parentheses).
Apr 01 2006
parent Cris <central_p hotmail.com> writes:
Thank you for your relies, John!


John C wrote:
 "Cris" <central_p hotmail.com> wrote in message 
 news:e0m0lc$2slj$1 digitaldaemon.com...
 Cris wrote:
 John C wrote:
 "Cris" <central_p hotmail.com> wrote in message 
 news:e0lr0p$2n17$1 digitaldaemon.com...
 How would you implement a  write only property?


in C#. Is it possible in D too?

Oh, yes it's possible: class Bicycle { this() { gear = 1; } int currentGear; int gear() { return currentGear; } void gear(int value) { currentGear = value; } }

But Bicycle.gear can be both read and written. I showed you in another reply how to do a write-only property.
 So it means that there is absolyutely no difference between properties and 
 functions in D? Perhaps the notion "property" is a little bit confusing in 
 this case.

This is why people keep suggesting an alternative syntax so that the compiler distinguishes between them. But it works most of the time, unless you're using it with auto type inference (in which case you need to use the parentheses).

Apr 01 2006
prev sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Cris" <central_p hotmail.com> wrote in message 
news:e0m0an$2sd1$1 digitaldaemon.com...
 John C wrote:
 "Cris" <central_p hotmail.com> wrote in message 
 news:e0lr0p$2n17$1 digitaldaemon.com...
 How would you implement a  write only property?

Implement only the setter.

I mean a property that you can write but you cannot read. You can do that in C#. Is it possible in D too?

As I said, implement only the setter. struct Foo { int data_; void data(int value) { data_ = value; } } void main() { Foo foo; foo.data = 10; int a = foo.data; // function main.Foo.data (int) does not match argument types. }
Apr 01 2006
parent Carlos Santander <csantander619 gmail.com> writes:
John C escribió:
 "Cris" <central_p hotmail.com> wrote in message 
 news:e0m0an$2sd1$1 digitaldaemon.com...
 John C wrote:
 "Cris" <central_p hotmail.com> wrote in message 
 news:e0lr0p$2n17$1 digitaldaemon.com...
 How would you implement a  write only property?


in C#. Is it possible in D too?

As I said, implement only the setter. struct Foo { int data_; void data(int value) { data_ = value; } } void main() { Foo foo; foo.data = 10; int a = foo.data; // function main.Foo.data (int) does not match argument types. }

Maybe that error message is another reason to have a true property syntax. For someone new to D expecting data to be a property, that message is as puzzling as it gets. -- Carlos Santander Bernal
Apr 01 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Cris" <central_p hotmail.com> wrote in message 
news:e0lg9c$27q4$1 digitaldaemon.com...
 Why the properties in D do not use the set/get syntax? It looks more clear 
 and natural to me.

I agree. With an explicit property syntax, more information could be given to the compiler as well, enabling things like obj.prop += 5; Which is currently not possible.
Apr 01 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 02 Apr 2006 11:31:13 +1000, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Cris" <central_p hotmail.com> wrote in message
 news:e0lg9c$27q4$1 digitaldaemon.com...
 Why the properties in D do not use the set/get syntax? It looks more  
 clear
 and natural to me.

I agree. With an explicit property syntax, more information could be given to the compiler as well, enabling things like obj.prop += 5; Which is currently not possible.

This is a compelling reason to have a specific syntax for properties. -- Derek Parnell Melbourne, Australia
Apr 01 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
Derek Parnell wrote:
 On Sun, 02 Apr 2006 11:31:13 +1000, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:
 
 "Cris" <central_p hotmail.com> wrote in message
 news:e0lg9c$27q4$1 digitaldaemon.com...
 Why the properties in D do not use the set/get syntax? It looks more 
 clear
 and natural to me.

I agree. With an explicit property syntax, more information could be given to the compiler as well, enabling things like obj.prop += 5; Which is currently not possible.

This is a compelling reason to have a specific syntax for properties. --Derek Parnell Melbourne, Australia

votes++
Apr 02 2006
prev sibling parent "Søren J. Løvborg" <web kwi.dk> writes:
Cris wrote:
 Why the properties in D do not use the set/get syntax? It looks more clear 
 and natural to me.

The big question is, which syntax? The (current) D way, with no explicit syntax for declaring properties: : int length() { return length_; } : void length(value) { length_ = value; } The C# way, with context-sensitive keywords "get"/"set", and implicit "value" variable: : int length { : get { return length_; } : set { length_ = value; } : } The Delphi/Object Pascal way (done C-style), with context-sensitive keywords "read"/"write": : property int length read getLength write setLength; :private: : int getLength() { return length_; } : void setLength(int value) { length_ = value; } Except that Object Pascal doesn't require one to write such trivial accessor methods, so this particular example becomes simply: : property int length read length_ write length_; I'm not really familiar with Python, but apparently there's a similar syntax (also done C-style here; Python's construct provides some more options that does not apply in D): : length = property(getLength, setLength) :private: : int getLength() { return length_; } : void setLength(int value) { length_ = value; } Advantages of the Python construct are the lack of context-sensitive keywords, and that it easily supports the same trick as Object Pascal, where simple getter/setter methods are implicit: : length = property(length_, length_) Of course, there's not much point in a property that simply gets and sets a member variable, but I find that you very often need a property that simply gets a member variable, and only performs special processing when setting the property. Thus, I also feel that any explicit property syntax should allow one to skip defining trivial getter methods. ------ Another, somewhat unrelated topic, is the semantics of properties -- just to throw some more balls into the air. In the previous thread, I notices James Dunne saying:
 Properties are meant to have the same semantics as methods, NOT fields. 
 They are made to have the same SYNTAX as fields.

I disagree. I find that the whole point of properties is to provide field-semantics, but with possible side-effects when setting the property. When I assign a value to a property, I expect to be able to read the property and get the same value, as if it was a field. Ex.: The text on a label (with some UI toolkit or other): : label.setText("Hi"); // side effect: the label is repainted. : return label.getText(); // returns "Hi". This is a prime candidate for using property syntax, exactly because of the field-like semantics: : label.text = "Hi"; // still has side effect, of course. : return label.text; // returns "Hi". A bad candidate for using property syntax (IMO) would be e.g.: : console.text = "Hello world."; // prints "Hello world." to the console. : return console.text; // reads a line of text from the console. Not only does console.text not return the value that was just assigned to it, it also changes its value everytime it's read. There are many on this NG (me included) that want the following to be legal for properties: : obj.prop++; Again, constructs like this one only makes sense if the property has field-like semantics. Whereas : console.text ~= "abc"; doesn't make a whole lot of sense. I'd also expect reading and writing of a property to be non-blocking and not terribly computationally expensive, so in my book, : thingymabob.terriblyComputationallyExpensiveOp = arg; is a big no-no, and should be: : thingymabob.terriblyComputationallyExpensiveOp(arg); Of course, this is a matter of preference. But basically, I find that both the programmer (and ideally the compiler) should be allowed to make some assumptions about properties. Example: : int sum = 0; : for (int i = 0; i < list.count; i ++) { sum += list.elements[i]; } If count is a field, the compiler only needs to evaluate it once, since the loop body is known to be side-effect free. Ideally, if count is a property, the compiler should be able to assume field-like semantics, and also only evalute it once. (Of course, if the loop body called any methods, or assigned to any properties, on any object, it would no longer be side-effect free, and the above optimizations would not apply, even if count was a field.) Note that list.elements could be an indexed property, if that was to be supported in D, and the compiler would still be allowed to assume no side-effects. I'm aware that in most languages, there are no such assumptions about properties: they are merely syntactic sugar. I'll propose that, if we introduce an explicit property syntax, we make it into more than just syntactic sugar. This would also introduce one of the (many) functionalities of C++'s const into D, namely constant member functions: In C++, the following explicitly states that the method has no side-effects: : int getLength() const; If we were to mandate field-like semantics for properties in D, we'd automatically have this functionality in property getters. (The fact that (some? many? all?) C++ compilers are over-zealous in their attempts to enforce the const'ness of constant methods, and how D should handle this, is really a separate discussion...) -- Søren J. Løvborg web kwi.dk
Apr 02 2006