Jump to page: 1 2 3
Thread overview
Proposal request: explicit propreties
Apr 01, 2008
Ary Borenszweig
Apr 01, 2008
Koroskin Denis
Apr 01, 2008
Aarti_pl
Apr 01, 2008
Jacob Carlborg
Apr 01, 2008
Koroskin Denis
Apr 01, 2008
Leandro Lucarella
Apr 01, 2008
Ary Borenszweig
Apr 01, 2008
Kenny B
Apr 01, 2008
Lionello Lunesu
Apr 01, 2008
Ary Borenszweig
Apr 02, 2008
Lionello Lunesu
Apr 02, 2008
Christopher Wright
Apr 02, 2008
Ary Borenszweig
Apr 02, 2008
Frits van Bommel
Apr 01, 2008
Simen Kjaeraas
Apr 01, 2008
Bill Baxter
Apr 01, 2008
Bill Baxter
Apr 01, 2008
naryl
Apr 01, 2008
Bill Baxter
Apr 01, 2008
Derek Parnell
Apr 01, 2008
Yigal Chripun
Apr 02, 2008
Robert Fraser
April 01, 2008
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
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
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
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
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
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
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
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
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
"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