Currently properties can have these forms:
Getter:
-------
Type property() {
// ...
}
Setter:
-------
void property(Type type) {
// ...
}
The problem is, the user can use them as functions or as properties. This is ok from the compiler point of view, but the code looks ugly if it doesn't make sense, like:
writefln = 5;
Further, if you want a function to be only used with property syntax, you can't. Why would you wan't that? Because if you have
class Foo {
int property() {
//
}
}
and then you decide to change it to
class Foo {
int property;
}
for some reason, code that used Foo.property() won't compile anymore.
I suggest marking properties as such like this:
getter Type property() {
// ...
}
setter void property() {
// ...
}
"getter" and "setter" are attributes, just like "public", "static", etc. The compiler only uses them to validate correct syntax usage. If they are applied to any other declaration that is not a function, an error is reported.
Finally, there is another reason for wanting to mark functions as properties: when you do autocompletion in an IDE, and it suggests you a function, it can't know whether to autocomplete it as a function or as a property. A solution could be writing something in the ddoc of that function, but since there's no standard for this, each IDE will invent it's own.
Of course, this is not backwards compatible, so it should be a D2 feature.
What do you think?

Agree. I have seen that both syntaxes are used (at some third party library) and I believe it is an inconsistency.
On Tue, 01 Apr 2008 17:21:19 +0400, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> Currently properties can have these forms:
>> Getter:
> -------
> Type property() {
> // ...
> }
>> Setter:
> -------
> void property(Type type) {
> // ...
> }
>> The problem is, the user can use them as functions or as properties. This is ok from the compiler point of view, but the code looks ugly if it doesn't make sense, like:
>> writefln = 5;
>> Further, if you want a function to be only used with property syntax, you can't. Why would you wan't that? Because if you have
>> class Foo {
>> int property() {
> //
> }
>> }
>> and then you decide to change it to
>> class Foo {
>> int property;
>> }
>> for some reason, code that used Foo.property() won't compile anymore.
>> I suggest marking properties as such like this:
>> getter Type property() {
> // ...
> }
>> setter void property() {
> // ...
> }
>> "getter" and "setter" are attributes, just like "public", "static", etc. The compiler only uses them to validate correct syntax usage. If they are applied to any other declaration that is not a function, an error is reported.
>> Finally, there is another reason for wanting to mark functions as properties: when you do autocompletion in an IDE, and it suggests you a function, it can't know whether to autocomplete it as a function or as a property. A solution could be writing something in the ddoc of that function, but since there's no standard for this, each IDE will invent it's own.
>> Of course, this is not backwards compatible, so it should be a D2 feature.
>> What do you think?

Ary Borenszweig wrote:
> Currently properties can have these forms:
> > Getter:
> -------
> Type property() {
> // ...
> }
> > Setter:
> -------
> void property(Type type) {
> // ...
> }
> > The problem is, the user can use them as functions or as properties. This is ok from the compiler point of view, but the code looks ugly if it doesn't make sense, like:
> > writefln = 5;
> > Further, if you want a function to be only used with property syntax, you can't. Why would you wan't that? Because if you have
> > class Foo {
> > int property() {
> //
> }
> > }
> > and then you decide to change it to
> > class Foo {
> > int property;
> > }
> > for some reason, code that used Foo.property() won't compile anymore.
> > I suggest marking properties as such like this:
> > getter Type property() {
> // ...
> }
> > setter void property() {
> // ...
> }
> > "getter" and "setter" are attributes, just like "public", "static", etc. The compiler only uses them to validate correct syntax usage. If they are applied to any other declaration that is not a function, an error is reported.
> > Finally, there is another reason for wanting to mark functions as properties: when you do autocompletion in an IDE, and it suggests you a function, it can't know whether to autocomplete it as a function or as a property. A solution could be writing something in the ddoc of that function, but since there's no standard for this, each IDE will invent it's own.
> > Of course, this is not backwards compatible, so it should be a D2 feature.
> > What do you think?
I like the way it is now because you don't have to write the () after a function call (taking no arguments) if you like but I understand why explicit properties would be a good thing. If explicit properties were introduced in the language I would like this syntax:
get T name (){}
set T name (){}
and also something I like to call property shortcut:
1) get string name;
2) set string name;
3) get set string name;
4) private set string name;
5) private set string name; public get string name;
6) static get string name;
7) get set
{
string name;
int age;
private string foo;
}
that would work something like read and write attributes in Ruby.
1) creates a private variable and a public get method
2) creates a private variable and a public set method
3) creates a private variable and a public get and set method
4) creates a private variable and a private set method
5) creates a private variable, a private set method and a public get method
6) creates a private static variable and a public static get method
7) creates three private variables, two public set methods (name and age), two public get methods (name and age), a private set method (foo) and a private get method (foo)
The thing is that the variables always should be private, the methods would be public as default and if you put a protection attribute (public, private, protected ...) in front of a property shortcut it should affect only the created method.

In my opinion, it is over-complicated.
On Tue, 01 Apr 2008 18:05:41 +0400, Jacob Carlborg <doobnet@gmail.com> wrote:
> Ary Borenszweig wrote:
> I like the way it is now because you don't have to write the () after a function call (taking no arguments) if you like but I understand why explicit properties would be a good thing. If explicit properties were introduced in the language I would like this syntax:
>> get T name (){}
> set T name (){}
>> and also something I like to call property shortcut:
>> 1) get string name;
> 2) set string name;
> 3) get set string name;
> 4) private set string name;
> 5) private set string name; public get string name;
> 6) static get string name;
> 7) get set
> {
> string name;
> int age;
> private string foo;
> }
>> that would work something like read and write attributes in Ruby.
> 1) creates a private variable and a public get method
> 2) creates a private variable and a public set method
> 3) creates a private variable and a public get and set method
> 4) creates a private variable and a private set method
> 5) creates a private variable, a private set method and a public get method
> 6) creates a private static variable and a public static get method
> 7) creates three private variables, two public set methods (name and age), two public get methods (name and age), a private set method (foo) and a private get method (foo)
>> The thing is that the variables always should be private, the methods would be public as default and if you put a protection attribute (public, private, protected ...) in front of a property shortcut it should affect only the created method.
>

Ary Borenszweig wrote:
> The problem is, the user can use them as functions or as properties. This is ok from the compiler point of view, but the code looks ugly if it doesn't make sense, like:
> > writefln = 5;
Code that doesn't make sense is always ugly.
Furthermore, I think that particular case can be fixed without removing the current syntax by limiting it's scope to functions with a single argument.
> Further, if you want a function to be only used with property syntax, you can't. Why would you wan't that? Because if you have
> > class Foo {
> > int property() {
> //
> }
> > }
> > and then you decide to change it to
> > class Foo {
> > int property;
> > }
> > for some reason, code that used Foo.property() won't compile anymore.
The whole point of property is that you can simply leave it as a function and the compiler will inline it if it turns out to be a trivial get/set. You're reasoning here is the wrong way around.
> Finally, there is another reason for wanting to mark functions as properties: when you do autocompletion in an IDE, and it suggests you a function, it can't know whether to autocomplete it as a function or as a property. A solution could be writing something in the ddoc of that function, but since there's no standard for this, each IDE will invent it's own.
This I don't get. Whether you want dummy "()" or not sounds like a style, much like space vs. tab, or tab size. IDE's can make it a user setting.
> Of course, this is not backwards compatible, so it should be a D2 feature.
> > What do you think?
I like the current "implicit getter/setter" very much and think it's one of the nicest features of D!
L.

On Tue, 01 Apr 2008 15:21:19 +0200, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> Finally, there is another reason for wanting to mark functions as properties: when you do autocompletion in an IDE, and it suggests you a function, it can't know whether to autocomplete it as a function or as a property. A solution could be writing something in the ddoc of that function, but since there's no standard for this, each IDE will invent it's own.
>> Of course, this is not backwards compatible, so it should be a D2 feature.
>> What do you think?
I like it the way it is. It's simple and, for the most part, logical. Though as
you say, it might be a problem for IDEs. However, I think if D should have
properties, that one should be able to customize them more. I've been working on
a property struct template, which allows you to customize its access (i.e
read-only, write-only, allow only certain operators...), as well as mixin
fuctions of your choice. And the syntax is pretty simple (though not perfect. I
wish there was some way to have it set up automagically, not in the
constructor):
class foo
{
private:
int _bar;
float _baz;
public:
// read-write property
property!(int, property.readwrite) bar;
// custom property that allows only addition and subtraction
property!(float, property.custom, "+,-", "+,-", "+=, -=") baz;
this()
{
bar = &_bar;
baz = &_baz;
}
}
foo f = new foo;
f.bar += 3;
I believe something like this would be more useful, as long as there were some
standard way to do it. Also, the syntax to mixin templates could do with some
sugar. What I'd really want'd be something like this:
class foo
{
private:
int _bar;
float _baz
string _faz;
public:
property!(_bar) bar;
property!(_baz, read) baz;
property!(_faz){
// methods to be mixed in
} baz;
}
--Simen

Lionello Lunesu wrote:
> Ary Borenszweig wrote:
>> The problem is, the user can use them as functions or as properties. This is ok from the compiler point of view, but the code looks ugly if it doesn't make sense, like:
>>>> writefln = 5;
> > Code that doesn't make sense is always ugly.
> > Furthermore, I think that particular case can be fixed without removing the current syntax by limiting it's scope to functions with a single argument.
> >> Further, if you want a function to be only used with property syntax, you can't. Why would you wan't that? Because if you have
>>>> class Foo {
>>>> int property() {
>> //
>> }
>>>> }
>>>> and then you decide to change it to
>>>> class Foo {
>>>> int property;
>>>> }
>>>> for some reason, code that used Foo.property() won't compile anymore.
> > The whole point of property is that you can simply leave it as a function and the compiler will inline it if it turns out to be a trivial get/set. You're reasoning here is the wrong way around.
To me, the idea of a property is: you use it as it were a field of a struct/class, but it's actually implemented by a function. You want to hide the implementation details from the user. You don't want them to know "Foo.property" is actually a function.
> >> Finally, there is another reason for wanting to mark functions as properties: when you do autocompletion in an IDE, and it suggests you a function, it can't know whether to autocomplete it as a function or as a property. A solution could be writing something in the ddoc of that function, but since there's no standard for this, each IDE will invent it's own.
> > This I don't get. Whether you want dummy "()" or not sounds like a style, much like space vs. tab, or tab size. IDE's can make it a user setting.
Take a look a this, from DFL:
---
class Form {
/// Sets the title of this form
void title(string text) {
// ...
}
}
class Application {
/// Runs an application whose main form is the given
static void run(Form form) {
//
}
}
---
Now you wan to code:
---
Form form = new Form();
form.title // <-- you wan't the IDE to suggest you a property, so
// you will end up having "form.title = text"
Application.run // <-- you wan't the IDE to suggest you a function,
// like "Application.run(form)"
// "Application.run = form" looks ugly, and no one
// would recommend you to write that
---
How do you configure this? On a per-property basis?
> >> Of course, this is not backwards compatible, so it should be a D2 feature.
>>>> What do you think?
> > I like the current "implicit getter/setter" very much and think it's one of the nicest features of D!
> > L.

"Ary Borenszweig" wrote
> Currently properties can have these forms:
>> Getter:
> -------
> Type property() {
> // ...
> }
>> Setter:
> -------
> void property(Type type) {
> // ...
> }
>> The problem is, the user can use them as functions or as properties. This is ok from the compiler point of view, but the code looks ugly if it doesn't make sense, like:
>> writefln = 5;
>> Further, if you want a function to be only used with property syntax, you can't. Why would you wan't that? Because if you have
>> class Foo {
>> int property() {
> //
> }
>> }
>> and then you decide to change it to
>> class Foo {
>> int property;
>> }
>> for some reason, code that used Foo.property() won't compile anymore.
>> I suggest marking properties as such like this:
>> getter Type property() {
> // ...
> }
>> setter void property() {
> // ...
> }
>> "getter" and "setter" are attributes, just like "public", "static", etc. The compiler only uses them to validate correct syntax usage. If they are applied to any other declaration that is not a function, an error is reported.
>> Finally, there is another reason for wanting to mark functions as properties: when you do autocompletion in an IDE, and it suggests you a function, it can't know whether to autocomplete it as a function or as a property. A solution could be writing something in the ddoc of that function, but since there's no standard for this, each IDE will invent it's own.
>> Of course, this is not backwards compatible, so it should be a D2 feature.
>> What do you think?
What about the C# way of doing it (or something similar)?
Type property
{
get
{
....
}
set
{
....
}
}
get and set don't have to be keywords in this context...
All in all, I'm not really upset with the way properties currently work, but I do prefer something explicit like this.
-Steve