properties - Why not the set/get syntax? (page 2) - D Programming Language Discussion Forum

April 02, 2006
Re: properties - Why not the set/get syntax?
Posted by Søren J. Løvborg
in reply to Cris
Permalink
Søren J. Løvborg
Posted in reply to Cris
Permalink
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
Forums
