View mode: basic / threaded / horizontal-split · Log in · Help
April 01, 2008
Proposal request: explicit propreties
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?
April 01, 2008
Re: Proposal request: explicit propreties
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?
April 01, 2008
Re: Proposal request: explicit propreties
Ary Borenszweig pisze:

...

> I suggest marking properties as such like this:
> 
> getter Type property() {
>   // ...
> }
> 
> setter void property() {
>   // ...
> }
> 

...

> What do you think?

Good rationale.

I just think that one keyword instead of setter/getter would be just 
enough. E.g 'property'.

BR
Marcin Kuszczak
April 01, 2008
Re: Proposal request: explicit propreties
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.
April 01, 2008
Re: Proposal request: explicit propreties
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.
>
April 01, 2008
Re: Proposal request: explicit propreties
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.
April 01, 2008
Re: Proposal request: explicit propreties
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
April 01, 2008
Re: Proposal request: explicit propreties
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.
April 01, 2008
Re: Proposal request: explicit propreties
Jacob Carlborg, el  1 de abril a las 16:05 me escribiste:
> get T name (){}
> set T name (){}

I don't think making 'get' and 'set' keywords is a good idea.

I like the 'property' keyword, it's just one keyword and it's used in
Python for the same thing.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Es mas posible, que un elefante maneje un cero km a que un camello
habite un departamento de un ambiente.
	-- Peperino PĆ³moro
April 01, 2008
Re: Proposal request: explicit propreties
"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
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home