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.



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;
 }



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;
 }



 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

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 




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 




 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?


 Implement only the setter.


 I mean a property that you can write but you cannot read. You can do that 



 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 



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?


 Implement only the setter.


 I mean a property that you can write but you cannot read. You can do that 



 
 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; }


"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