Eigenpoll : D wish list : Property declarator

I think it could be good if we had a property declarator which would be clearer enough to tell if the property is read only, write only, or both.

For example:

class Foo {
public property Foobar foobar {
get {return propz;}
set {propz = value;}
}
public virtual property bool foobarEnabled {
get {return foobar is null;}
}
}
Foo t = new Foo();
t.foobar = new Foobar();
if (t.foobar instanceof Foobar) {...}
if (t.foobarEnabled) ...

Now let explains the syntax:

[virtual] property Foobar foobar:

Declare a property named foobar, of type Foobar. The "virtual" keyword indicate the property is virtual, eg: computed from a state, or something else. Else, the property exist as a private member of the class. eg:

private Foobar _foobar;
public virtual property Foobar foobar {
get {return _foobar;}
set {_foobar = value;}
}

And:

public property Foobar foobar {
get {return property;}
set {property = value;}
}

get {...}:

Declare the getter of a property. For non virtual property, the value is accessible using some keyword (here property, but I guess it will create conflict in D grammar, so...

This make the property readable. Note that for non virtual property, the code will mostly ressemble to get {return property;} for most of properties, so perhaps we could just use get without instruction:

public property Foobar foobar {
get;
}

set {...}

This make the property writable. The r-value - eg: the supposed new value of the property - is here named value, but it can be something else. Like for get, we can also have:

public property Foobar foobar {
set;
}

By default, a property is 1) not readable 2) not writable. Since it kinda strange to declare such stuff, I propose that when the property is declared like that:

public property Foobar foobar;

It is set as public read and write property.

And finally, we could also change visibility of get/set:

public property Foobar foobar {
private set;
public get;
}

We can read property outside class scope, but we can not write property outside. It's like:

public Foobar getFoobar() {}
private void setFoobar(Foobar fb) {}

In this case, the visibility modifier before property act as a global visibility modifier:

(default, none set), public: get and set are both public (default), unless a specific visibility modifier is used on get/set.
protected: get and set are both protected. Only a private visibility modifier can be used on get/set
private: get and set are both private.

Advantages are the following:

1) implicitly declare the property holder (here: propz, of type Foobar). This could be disabled.
2) put in the same place the getter and the setter for the property
3) behave exactly like a private member of a class
4) no need to declare type for get() and set(), as it set for the property.

Report this item for cleanup