www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Reddit: why aren't people using D?

reply Kagamin <spam here.lot> writes:
Walter Bright Wrote:


 Properties. Your syntactic sugar:
 
 int i = c.p; // int i = c.p()
 p = i // c.p(i)
 
 They can't do these things:
 
 * No control over their use by class designer: ANY member function with one
 or zero parameters may be called using 'property syntax'. This is not a
 good thing.



 Why not? Seriously, what is the semantic difference?
 



Functions used to denote arbitrary "actions", while properties are designed to
simulate data rather than functions: fields with minor logic concerning
accessing them, e.g. input validation. This got reflected in naming conventions
directing to name functions with verbs and properties and fields with nouns.
Properties being implemented by functions is a technical detail, which may
change: the property logic can become declarative or come in a form of type
checking and be tested by caller, or most probably it can be replaced by
invariant altogether. All these alternative solutions have their certain
limitations or advantages, but they effectively do the same thing as
"functional" properties without changing their semantics. That's why properties
are not functions.
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Kagamin wrote:

 Walter Bright Wrote:
 

 Properties. Your syntactic sugar:
 
 int i = c.p; // int i = c.p() p = i // c.p(i)
 
 They can't do these things:
 
 * No control over their use by class designer: ANY member
 function with one or zero parameters may be called using
 'property syntax'. This is not a good thing.



 



 arbitrary "actions", while properties are designed to simulate data
 rather than functions: fields with minor logic concerning accessing
 them, e.g. input validation.



I so don't get this. Yes, functions are used to denote arbitrary 
actions. Some of these actions can set and get state. It is convenient 
to benefit of some syntactic aid for those cases (e.g. make their use 
look and feel like fields). So far so good. But as long as there is no 
innate validation or enforcement from the compiler that for example you 
setFoo(5) ensures that getFoo() will get you 5, we're only talking about 
syntactic convenience. This is it: syntactic convenience. Nothing else.


 This got reflected in naming conventions
 directing to name functions with verbs and properties and fields with
 nouns.



Fine.


 Properties being implemented by functions is a technical
 detail, which may change: the property logic can become declarative
 or come in a form of type checking and be tested by caller, or most
 probably it can be replaced by invariant altogether.



I don't understand this.


 All these
 alternative solutions have their certain limitations or advantages,
 but they effectively do the same thing as "functional" properties
 without changing their semantics. 



And consequently this.


 That's why properties are not
 functions.



This post had a negative effect on me: I now think properties are 
functions even more than before.


Andrei
Jul 27 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Kagamin wrote:

 Walter Bright Wrote:


 Properties. Your syntactic sugar:

 int i = c.p; // int i = c.p() p = i // c.p(i)

 They can't do these things:

 * No control over their use by class designer: ANY member
 function with one or zero parameters may be called using
 'property syntax'. This is not a good thing.






 arbitrary "actions", while properties are designed to simulate data
 rather than functions: fields with minor logic concerning accessing
 them, e.g. input validation.



 I so don't get this. Yes, functions are used to denote arbitrary 
 actions. Some of these actions can set and get state. It is convenient 
 to benefit of some syntactic aid for those cases (e.g. make their use 
 look and feel like fields). So far so good. But as long as there is no 
 innate validation or enforcement from the compiler that for example you 
 setFoo(5) ensures that getFoo() will get you 5, we're only talking about 
 syntactic convenience. This is it: syntactic convenience. Nothing else.
 

 This got reflected in naming conventions
 directing to name functions with verbs and properties and fields with
 nouns.



 Fine.
 

 Properties being implemented by functions is a technical
 detail, which may change: the property logic can become declarative
 or come in a form of type checking and be tested by caller, or most
 probably it can be replaced by invariant altogether.



 I don't understand this.
 

 All these
 alternative solutions have their certain limitations or advantages,
 but they effectively do the same thing as "functional" properties
 without changing their semantics. 



 And consequently this.
 

 That's why properties are not
 functions.



 This post had a negative effect on me: I now think properties are 
 functions even more than before.



I think the only way you and Walter can understand what a property is 
and what it is used for is to use for some time a language that 
implements them. For example C#. Then you'll say "that's nice" and would 
want to implement it in D.
Jul 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:

 I think the only way you and Walter can understand what a property is 
 and what it is used for is to use for some time a language that 
 implements them. For example C#. Then you'll say "that's nice" and would 
 want to implement it in D.



I totally agree that "that's nice". But it's just notational 
convenience, and there was no proof aired here to convince me otherwise.

Andrei
Jul 27 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 I think the only way you and Walter can understand what a property is 
 and what it is used for is to use for some time a language that 
 implements them. For example C#. Then you'll say "that's nice" and 
 would want to implement it in D.



 I totally agree that "that's nice". But it's just notational 
 convenience, and there was no proof aired here to convince me otherwise.
 
 Andrei



The ambiguity with a function returning a delegate? The debugger 
support? Help UI designers with properties windows?

If none of those convinced you, ok.
Jul 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 I think the only way you and Walter can understand what a property is 
 and what it is used for is to use for some time a language that 
 implements them. For example C#. Then you'll say "that's nice" and 
 would want to implement it in D.



 I totally agree that "that's nice". But it's just notational 
 convenience, and there was no proof aired here to convince me otherwise.

 Andrei



 The ambiguity with a function returning a delegate? The debugger 
 support? Help UI designers with properties windows?
 
 If none of those convinced you, ok.



Convince me of what? Of the fact that the current design has problems, 
absolutely. That we need to embark on all sorts of baroque notations for 
the sake of a convenience, not quite.

Andrei
Jul 27 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 I think the only way you and Walter can understand what a property 
 is and what it is used for is to use for some time a language that 
 implements them. For example C#. Then you'll say "that's nice" and 
 would want to implement it in D.



 I totally agree that "that's nice". But it's just notational 
 convenience, and there was no proof aired here to convince me otherwise.

 Andrei



 The ambiguity with a function returning a delegate? The debugger 
 support? Help UI designers with properties windows?

 If none of those convinced you, ok.



 Convince me of what? Of the fact that the current design has problems, 
 absolutely. That we need to embark on all sorts of baroque notations for 
 the sake of a convenience, not quite.
 
 Andrei



I agree. It's very hard to find the correct way to implement it... :(
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 I think the only way you and Walter can understand what a property 
 is and what it is used for is to use for some time a language that 
 implements them. For example C#. Then you'll say "that's nice" and 
 would want to implement it in D.



 I totally agree that "that's nice". But it's just notational 
 convenience, and there was no proof aired here to convince me 
 otherwise.

 Andrei



 The ambiguity with a function returning a delegate? The debugger 
 support? Help UI designers with properties windows?

 If none of those convinced you, ok.



 Convince me of what? Of the fact that the current design has problems, 
 absolutely. That we need to embark on all sorts of baroque notations 
 for the sake of a convenience, not quite.

 Andrei



 I agree. It's very hard to find the correct way to implement it... :(



Might be because (a) we aren't getting our priorities right, (b) we 
ascribe more to properties than what the compiler really makes of them.

At the end of the day, a property is a notational convenience. Instead 
of writing:

obj.set_xyz(5);
int a = obj.get_xyz();

properties allow us to write:

obj.xyz = 5;
int a = obj.xyz;

Just to be 100% clear, I agree that the convenience is great. But I 
don't know why the hell I need to learn a whole different syntax for 
*defining* such things, when the compiler itself doesn't give a damn - 
it just blindly rewrites the latter into something like the former.

Now to be 101% clear, I also understand that the current design sucks. 
But what I want is to come with a new design that adds minimum 
aggravation on the learning programmer. If they know how to define a 
method, they must know how to define a property. None of that property 
blah { get ... set ... } crap is necessary.


Andrei
Jul 27 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 I think the only way you and Walter can understand what a property 
 is and what it is used for is to use for some time a language that 
 implements them. For example C#. Then you'll say "that's nice" and 
 would want to implement it in D.



 I totally agree that "that's nice". But it's just notational 
 convenience, and there was no proof aired here to convince me 
 otherwise.

 Andrei



 The ambiguity with a function returning a delegate? The debugger 
 support? Help UI designers with properties windows?

 If none of those convinced you, ok.



 Convince me of what? Of the fact that the current design has 
 problems, absolutely. That we need to embark on all sorts of baroque 
 notations for the sake of a convenience, not quite.

 Andrei



 I agree. It's very hard to find the correct way to implement it... :(



 Might be because (a) we aren't getting our priorities right, (b) we 
 ascribe more to properties than what the compiler really makes of them.
 
 At the end of the day, a property is a notational convenience. Instead 
 of writing:
 
 obj.set_xyz(5);
 int a = obj.get_xyz();
 
 properties allow us to write:
 
 obj.xyz = 5;
 int a = obj.xyz;
 
 Just to be 100% clear, I agree that the convenience is great. But I 
 don't know why the hell I need to learn a whole different syntax for 
 *defining* such things, when the compiler itself doesn't give a damn - 
 it just blindly rewrites the latter into something like the former.
 
 Now to be 101% clear, I also understand that the current design sucks. 
 But what I want is to come with a new design that adds minimum 
 aggravation on the learning programmer. If they know how to define a 
 method, they must know how to define a property. None of that property 
 blah { get ... set ... } crap is necessary.



Again, I agree. I think just a minimal change is required to accomplish 
that. See my other post:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=93751

(but I think it should be "property int" instead of "int property", 
because modifiers can't come after the type).
Jul 27 2009
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:

...

 At the end of the day, a property is a notational convenience. 



That sums up the discussion pretty nicely. Except for one thing: what do you 
think of the ability of tools ( I include metaprogramming with this ) to 
recognize properties as such?
Jul 27 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lutger wrote:

 Andrei Alexandrescu wrote:
 
 ...

 At the end of the day, a property is a notational convenience. 



 That sums up the discussion pretty nicely. Except for one thing: what do you 
 think of the ability of tools ( I include metaprogramming with this ) to 
 recognize properties as such? 



They'd employ whatever means the language has for enabling the 
notational convenience.

Andrei
Jul 27 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h4kkn3$14pv$1 digitalmars.com...

 But what I want is to come with a new design that adds minimum aggravation 
 on the learning programmer. If they know how to define a method, they must 
 know how to define a property. None of that property blah { get ... set 
 ... } crap is necessary.



I can't be nice about this: Any programmer who has *any* aggrivation 
learning any even remotely sane property syntax is an idiot, period. They'd 
have to be incompetent to not be able to look at an example like this:

// Fine, I'll throw DRY away:
int _width;
int width
{
    get { return _width; }
    set(v) { _width = v; }
}

And immediately know exactly how the poroperty syntax works.

Plus, damn near every other common language out there these days has some 
form of property syntax (except maybe C++, but that's just a steaming pile 
anyway, and anyone who can get used to that garbage is going to be among the 
last people to hit stumbling blocks over a modern property syntax). So prior 
experience with real property syntax is extremely common. Plus, none of the 
people using those langauges have had trouble with these property syntaxes 
anyway. It's a complete non-issue.

While we're at it, let's just throw away for and foreach, after all, there 
can't possibly be any point to those if you already have while! Why should 
we give people new to D the aggrivation of having to learn for and foreach 
syntax?
Jul 27 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4kkn3$14pv$1 digitalmars.com...
 While we're at it, let's just throw away for and foreach, after all, there 
 can't possibly be any point to those if you already have while! Why should 
 we give people new to D the aggrivation of having to learn for and foreach 
 syntax?



Throw while too, we have goto!
Jul 27 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4kkn3$14pv$1 digitalmars.com...

 But what I want is to come with a new design that adds minimum aggravation 
 on the learning programmer. If they know how to define a method, they must 
 know how to define a property. None of that property blah { get ... set 
 ... } crap is necessary.



 I can't be nice about this: Any programmer who has *any* aggrivation 
 learning any even remotely sane property syntax is an idiot, period. They'd 
 have to be incompetent to not be able to look at an example like this:
 
 // Fine, I'll throw DRY away:
 int _width;
 int width
 {
     get { return _width; }
     set(v) { _width = v; }
 }
 
 And immediately know exactly how the poroperty syntax works.



Sure. My point is that with using standard method definition syntax 
there's no need for even looking over an example.


 Plus, damn near every other common language out there these days has some 
 form of property syntax (except maybe C++, but that's just a steaming pile 
 anyway, and anyone who can get used to that garbage is going to be among the 
 last people to hit stumbling blocks over a modern property syntax). So prior 
 experience with real property syntax is extremely common. Plus, none of the 
 people using those langauges have had trouble with these property syntaxes 
 anyway. It's a complete non-issue.



Java too I guess.


 While we're at it, let's just throw away for and foreach, after all, there 
 can't possibly be any point to those if you already have while! Why should 
 we give people new to D the aggrivation of having to learn for and foreach 
 syntax?



Removing foreach would make code more verbose. Adding property crap 
would make code more verbose.


Andrei
Jul 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu wrote:

 Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4kkn3$14pv$1 digitalmars.com...

 But what I want is to come with a new design that adds minimum 
 aggravation on the learning programmer. If they know how to define a 
 method, they must know how to define a property. None of that 
 property blah { get ... set ... } crap is necessary.



 I can't be nice about this: Any programmer who has *any* aggrivation 
 learning any even remotely sane property syntax is an idiot, period. 
 They'd have to be incompetent to not be able to look at an example 
 like this:

 // Fine, I'll throw DRY away:
 int _width;
 int width
 {
     get { return _width; }
     set(v) { _width = v; }
 }

 And immediately know exactly how the poroperty syntax works.



 Sure. My point is that with using standard method definition syntax 
 there's no need for even looking over an example.



PLUS:

* need to remember that get is not followed by ()

* need to remember that set does not take a type like any other 
function, just an identifier

* need to remember that there is no () after width

WHY? Do you have just one reason for which all this is necessary?


Andrei
Jul 27 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h4l4nr$20u0$4 digitalmars.com...

 Sure. My point is that with using standard method definition syntax 
 there's no need for even looking over an example.






So people are going to automagically just *know* to stick "opGet_" in front 
of the name to make it a property?


 PLUS:

 * need to remember that get is not followed by ()



1. That's trivial to remember.
2. Ok, so we can stick a () after get.


 * need to remember that set does not take a type like any other function, 
 just an identifier



set(auto v)
Problem solved.

Plus with both of the above, you're seem to be using arguments against a 
specific decicated property syntax as as arguments against dedicated 
property syntaxes in general.


 * need to remember that there is no () after width



Why in the world would there be? It's not a function.
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4l4nr$20u0$4 digitalmars.com...

 Sure. My point is that with using standard method definition syntax 
 there's no need for even looking over an example.






 So people are going to automagically just *know* to stick "opGet_" in front 
 of the name to make it a property?



It's ONE rule to remember, and it blends perfectly with the rest of the 
language. Compare that with the bunch of arbitrary rules that you propose.


 PLUS:

 * need to remember that get is not followed by ()



 1. That's trivial to remember.



No. "Trivial to remember" is far from enough. You need to justify why 
there's anything I need to remember in the first place.


 2. Ok, so we can stick a () after get.



Ok, so it's an arbitrary rule. Why exactly is it necessary?


 * need to remember that set does not take a type like any other function, 
 just an identifier



 set(auto v)
 Problem solved.



Yah, "solved" with more arbitrary syntax. I love this.


 Plus with both of the above, you're seem to be using arguments against a 
 specific decicated property syntax as as arguments against dedicated 
 property syntaxes in general.
 

 * need to remember that there is no () after width



 Why in the world would there be? It's not a function.



Well I don't know what it is, so there might as well be some parens in 
there. It's all arbitrary after all. Syntax upon syntax upon syntax. Why 
do we need it?

This looks like switch all over again :o).


Andrei
Jul 27 2009
parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h4l83a$27u6$1 digitalmars.com...

 Well I don't know what it is, so there might as well be some parens in 
 there. It's all arbitrary after all. Syntax upon syntax upon syntax. Why 
 do we need it?

 This looks like switch all over again :o).



Well let's just throw away all our high-level syntax then and go back to 
machine code.
Jul 27 2009
prev sibling parent reply John C <johnch_atms hotmail.com> writes:
Andrei Alexandrescu wrote:

 Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4kkn3$14pv$1 digitalmars.com...

 But what I want is to come with a new design that adds minimum 
 aggravation on the learning programmer. If they know how to define a 
 method, they must know how to define a property. None of that 
 property blah { get ... set ... } crap is necessary.



 I can't be nice about this: Any programmer who has *any* aggrivation 
 learning any even remotely sane property syntax is an idiot, period. 
 They'd have to be incompetent to not be able to look at an example 
 like this:

 // Fine, I'll throw DRY away:
 int _width;
 int width
 {
     get { return _width; }
     set(v) { _width = v; }
 }

 And immediately know exactly how the poroperty syntax works.



 Sure. My point is that with using standard method definition syntax 
 there's no need for even looking over an example.
 



Which is why Steven Schveighoffer's is suggestion is the most pragmatic 
so far. You just add a "property" attribute to a regular function 
definition. (And it doesn't look ugly, unlike the opGet_/opSet_ idea.)
Jul 27 2009
parent reply grauzone <none example.net> writes:
Bill Baxter wrote:

 On Mon, Jul 27, 2009 at 2:24 PM, John C<johnch_atms hotmail.com> wrote:

 Andrei Alexandrescu wrote:

 Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:h4kkn3$14pv$1 digitalmars.com...

 But what I want is to come with a new design that adds minimum
 aggravation on the learning programmer. If they know how to define a method,
 they must know how to define a property. None of that property blah { get
 ... set ... } crap is necessary.



 learning any even remotely sane property syntax is an idiot, period. They'd
 have to be incompetent to not be able to look at an example like this:

 // Fine, I'll throw DRY away:
 int _width;
 int width
 {
    get { return _width; }
    set(v) { _width = v; }
 }

 And immediately know exactly how the poroperty syntax works.



 there's no need for even looking over an example.



 far. You just add a "property" attribute to a regular function definition.
 (And it doesn't look ugly, unlike the opGet_/opSet_ idea.)



 +1.
 That's really all that's needed.  A simple flag to say "this function
 acts like a field".



Also note that the syntactic sugar could be implemented as library, 
using macros. Too bad macros were left to D3.0, even though Walter added 
a "macro" keyword. (Which was also a breaking change to the finalized 
D1.0, blergh.)

That said, it would be really convenient for mixed compile time/runtime 
meta programming to be able to associate additional information to a 
method or a field. Like marking a method as property. Java and C# have 
attribute syntax for this. This would be useful for reflection, 
serialization, IDEs, and other modern day crap like this.

Additionally, a "readonly" modifier would eliminate lots of uses of 
properties: often, you just want to make a field not writeable from 
outside. Normally, you would make the field private, and add a public 
readonly getter. Note that making the field immutable is not enough, 
because it can't be written by the class.
Jul 27 2009
parent reply grauzone <none example.net> writes:
grauzone wrote:

 That said, it would be really convenient for mixed compile time/runtime 
 meta programming to be able to associate additional information to a 
 method or a field. Like marking a method as property. Java and C# have 
 attribute syntax for this. This would be useful for reflection, 
 serialization, IDEs, and other modern day crap like this.



Oops, "annotations" is the term in use, not "attributes".
Jul 27 2009
parent "Nick Sabalausky" <a a.a> writes:
"grauzone" <none example.net> wrote in message 
news:h4lnpn$11h$1 digitalmars.com...

 grauzone wrote:

 That said, it would be really convenient for mixed compile time/runtime 
 meta programming to be able to associate additional information to a 
 method or a field. Like marking a method as property. Java and C# have 
 attribute syntax for this. This would be useful for reflection, 
 serialization, IDEs, and other modern day crap like this.



 Oops, "annotations" is the term in use, not "attributes".



Either way. Java calls them annotations, C# calls them attributes.
Jul 27 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Nick Sabalausky wrote:

 I can't be nice about this: Any programmer who has *any* aggrivation 
 learning any even remotely sane property syntax is an idiot, period. They'd 
 have to be incompetent to not be able to look at an example like this:
 
 // Fine, I'll throw DRY away:
 int _width;
 int width
 {
     get { return _width; }
     set(v) { _width = v; }
 }
 
 And immediately know exactly how the poroperty syntax works.



I don't know exactly how this is supposed to work.  The basic idea is
obvious, but:
  - How does it interact with inheritance?  Can I override properties?
Can I partially override properties (setter but not getter)?
  - Can I write a setter that accepts another type?
  - Can I write a templated setter that accepts *all* types?  If so, how?
  - Can I create a delegate from a setter/getter?  If so, how?
  - I assume that getters/setters can have individual access specifiers
(i.e. private/protected/public), but is that really the case?

Dedicated property syntax isn't hard to learn, but it's not as obvious
as you make it our to be.  Note that none of these issues exist with
opGet_foo, which follows the same rules as all functions.


-- 
Rainer Deyke - rainerd eldwood.com
Jul 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:

 Nick Sabalausky wrote:

 I can't be nice about this: Any programmer who has *any* aggrivation 
 learning any even remotely sane property syntax is an idiot, period. They'd 
 have to be incompetent to not be able to look at an example like this:

 // Fine, I'll throw DRY away:
 int _width;
 int width
 {
     get { return _width; }
     set(v) { _width = v; }
 }

 And immediately know exactly how the poroperty syntax works.



 I don't know exactly how this is supposed to work.  The basic idea is
 obvious, but:
   - How does it interact with inheritance?  Can I override properties?
 Can I partially override properties (setter but not getter)?
   - Can I write a setter that accepts another type?
   - Can I write a templated setter that accepts *all* types?  If so, how?
   - Can I create a delegate from a setter/getter?  If so, how?
   - I assume that getters/setters can have individual access specifiers
 (i.e. private/protected/public), but is that really the case?
 
 Dedicated property syntax isn't hard to learn, but it's not as obvious
 as you make it our to be.  Note that none of these issues exist with
 opGet_foo, which follows the same rules as all functions.
 
 



+1

Andrei
Jul 27 2009
parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 Rainer Deyke wrote:

 Nick Sabalausky wrote:

 I can't be nice about this: Any programmer who has *any* aggrivation 
 learning any even remotely sane property syntax is an idiot, period. 
 They'd have to be incompetent to not be able to look at an example 
 like this:

 // Fine, I'll throw DRY away:
 int _width;
 int width
 {
     get { return _width; }
     set(v) { _width = v; }
 }

 And immediately know exactly how the poroperty syntax works.



 I don't know exactly how this is supposed to work.  The basic idea is
 obvious, but:
   - How does it interact with inheritance?  Can I override properties?
 Can I partially override properties (setter but not getter)?
   - Can I write a setter that accepts another type?
   - Can I write a templated setter that accepts *all* types?  If so, how?
   - Can I create a delegate from a setter/getter?  If so, how?
   - I assume that getters/setters can have individual access specifiers
 (i.e. private/protected/public), but is that really the case?

 Dedicated property syntax isn't hard to learn, but it's not as obvious
 as you make it our to be.  Note that none of these issues exist with
 opGet_foo, which follows the same rules as all functions.



 +1
 
 Andrei



Also agree. The C# syntax is a little too complex for my taste, and it 
makes some things ugly or impossible (like, what if I want a public 
getter but a protected setter?)

I like the mechanics of the opGet_Xxx proposal, but aesthetically, it 
just makes my eyes bleed (as do the other "op" functions, like opApply, 
that don't technically overload any "op"erators).

For my money, the best solution is a simple "property" keyword as a 
function modifier. Only functions with the "property" modifier would be 
allowed to pose as fields (getters called without parens, setters called 
using assignment syntax). But, in all other respects, they should act 
just like functions.

--benji
Jul 27 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Benji Smith wrote:

 For my money, the best solution is a simple "property" keyword as a
 function modifier. Only functions with the "property" modifier would be
 allowed to pose as fields (getters called without parens, setters called
 using assignment syntax). But, in all other respects, they should act
 just like functions.



I like being able to distinguish between the property itself and its
setter/getter function.

For example, let's say 'y' is a property of 'x'.

z = x.y; // Calls the getter.
x.y = z; // Calls the setter.
z = &x.y; // But what's this?  The setter, the getter, or the property
itself?

That's why I support opSet_foo and opGet_foo (although I'd prefer the
simpler get_foo and set_foo).


-- 
Rainer Deyke - rainerd eldwood.com
Jul 27 2009
next sibling parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Rainer Deyke wrote:


 For my money, the best solution is a simple "property" keyword as a
 function modifier. Only functions with the "property" modifier would be
 allowed to pose as fields (getters called without parens, setters called
 using assignment syntax). But, in all other respects, they should act
 just like functions.



 I like being able to distinguish between the property itself and its
 setter/getter function.



May I remind the group of a possible solution I've offered before?

Here it is, slightly modified to go along with the current "no grouping of
setters and getters" trend.

--------------------------------------------------
class C {
    int foo.get() { ... }
    void foo.set(int value) { ... }
}

C c;
c.foo = 5; // c.foo.set(5);
i = c.foo; // i = c.foo.get();
d = &c.foo.get; // d = delegate to foo getter
--------------------------------------------------

It doesn't make your eyes bleed (I think). And you have a way to distinguish
between getter, setter and property.

The downside for D is that get() and set() may overshadow member functions
of the property type.

In my own language, this is not an issue, since get() and set() are special
functions that have the same meaning for each type. And overriding them is
just what a property is supposed to do.

-- 
Michiel Helvensteijn
Jul 28 2009
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
Rainer Deyke wrote:

 Benji Smith wrote:

 For my money, the best solution is a simple "property" keyword as a
 function modifier. Only functions with the "property" modifier would be
 allowed to pose as fields (getters called without parens, setters called
 using assignment syntax). But, in all other respects, they should act
 just like functions.



 I like being able to distinguish between the property itself and its
 setter/getter function.
 
 For example, let's say 'y' is a property of 'x'.
 
 z = x.y; // Calls the getter.
 x.y = z; // Calls the setter.
 z = &x.y; // But what's this?  The setter, the getter, or the property
 itself?
 



class X {
   int _y;
   property pure const int y() { return _y; }
   property void y(int y_) { _y = y_; }
   pure const int y(int i, int j) { return _y+i*j; }
};

auto x = new X;
int delegate() z_getter = &x.y;
void delegate(int) z_setter = &x.y;
int delegate(int,int) z_irrelevant = &x.y;
int* z_variable = &x._y;
// What do you mean by "the property itself"? there's no single address 
to such thing.

z_setter(16);
assert(z_getter() == 16);
assert(z_irrelevant(3,4) == 28);
assert(*z_variable == 16);



 That's why I support opSet_foo and opGet_foo (although I'd prefer the
 simpler get_foo and set_foo).
Jul 28 2009
prev sibling parent reply sclytrack <sclytrack pi.be> writes:
   - How does it interact with inheritance?  Can I override properties?




 Can I partially override properties (setter but not getter)?




   - Can I write a setter that accepts another type?




   - Can I write a templated setter that accepts *all* types?  If so, how?




   - Can I create a delegate from a setter/getter?  If so, how?




   - I assume that getters/setters can have individual access specifiers




 (i.e. private/protected/public), but is that really the case?



-------------------
	property -> prop  (it appears billions of times)
-------------------
	How about big letters?

	string Name(){}
	void Name(string) {}
	void doStuff(string) {}
-------------------
	1. To show up differently from the normal methods
           in the reflection to be used by the IDE.

	2. To behave like fields with respect to +=, and other stuff.

	Number (1) is the only thing that Delphi does, it does
	not have operator overloading like (2).

	The D compiler does not need any distinction between
	the normal methods, and the "ones" to be shown in the IDE
	because it does not create the reflection information,
	(to be used by the IDE)
-------------------
	Constraints on properties, but NOT relevant
	(skip this text)

	1. No multiple parameters
	void setPosition(double, double) {}

	2. No overloads
	void setPosition( Vec2 ) {}
	void setPosition( Point2 ) {}

	The IDE could pick the ones that have
	minimum a getter, hence not relevant.
	(I think)

	3. Both at the same time. (C#)
	virtual setPosition()
	virtual getPosition()

        public override double Area {
          get {return mySide * mySide;}
        }

	4. Not same name as methods.

        5. ... working on this one...


	D style properties are less restrictive.
--------------------
	Java Annotations provide a more
	GENERAL way to "tag" methods, by
	providing user defined Annotations.
	(Heavily used in EJB 3.0)

	 Prop
	public String name() {}

	The API provides routines like
	.getAnnotations()
	.isAnnotationPresent()

	Again D does not create the
	reflection information to be
	used by the IDE.
--------------------
	(skip the following text)

	Chocomilk is very good, I drink
	it every morning. I don't know
	why? I just like it. Also I just don't
	understand those coffee people.
	How can they drink that discusting
	juice every day, make jokes about it
	every morning?

	No for me a nice cup of warm chocolate milk.
Jul 27 2009
parent KennyTM~ <kennytm gmail.com> writes:
sclytrack wrote:

   - How does it interact with inheritance?  Can I override properties?




 Can I partially override properties (setter but not getter)?




   - Can I write a setter that accepts another type?




   - Can I write a templated setter that accepts *all* types?  If so, how?




   - Can I create a delegate from a setter/getter?  If so, how?




   - I assume that getters/setters can have individual access specifiers




 (i.e. private/protected/public), but is that really the case?



 -------------------
 	property -> prop  (it appears billions of times)
 -------------------
 	How about big letters?



How about identifiers starting with ß? _?


 
 	string Name(){}
 	void Name(string) {}
 	void doStuff(string) {}
 -------------------
 	1. To show up differently from the normal methods
            in the reflection to be used by the IDE.
 
 	2. To behave like fields with respect to +=, and other stuff.
 
 	Number (1) is the only thing that Delphi does, it does
 	not have operator overloading like (2).
 
 	The D compiler does not need any distinction between
 	the normal methods, and the "ones" to be shown in the IDE
 	because it does not create the reflection information,
 	(to be used by the IDE)
 -------------------
 	Constraints on properties, but NOT relevant
 	(skip this text)
 
 	1. No multiple parameters
 	void setPosition(double, double) {}
 
 	2. No overloads
 	void setPosition( Vec2 ) {}
 	void setPosition( Point2 ) {}
 
 	The IDE could pick the ones that have
 	minimum a getter, hence not relevant.
 	(I think)
 
 	3. Both at the same time. (C#)
 	virtual setPosition()
 	virtual getPosition()
 
         public override double Area {
           get {return mySide * mySide;}
         }
 
 	4. Not same name as methods.
 
         5. ... working on this one...
 
 
 	D style properties are less restrictive.
 --------------------
 	Java Annotations provide a more
 	GENERAL way to "tag" methods, by
 	providing user defined Annotations.
 	(Heavily used in EJB 3.0)
 
 	 Prop
 	public String name() {}
 
 	The API provides routines like
 	.getAnnotations()
 	.isAnnotationPresent()
 
 	Again D does not create the
 	reflection information to be
 	used by the IDE.
 --------------------
 	(skip the following text)
 
 	Chocomilk is very good, I drink
 	it every morning. I don't know
 	why? I just like it. Also I just don't
 	understand those coffee people.
 	How can they drink that discusting
 	juice every day, make jokes about it
 	every morning?
 
 	No for me a nice cup of warm chocolate milk.
Jul 28 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 27, 2009 at 3:01 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:h4l4nr$20u0$4 digitalmars.com...

 Sure. My point is that with using standard method definition syntax
 there's no need for even looking over an example.






 So people are going to automagically just *know* to stick "opGet_" in
 front of the name to make it a property?



 It's ONE rule to remember, and it blends perfectly with the rest of the
 language. Compare that with the bunch of arbitrary rules that you propose.


 PLUS:

 * need to remember that get is not followed by ()



 1. That's trivial to remember.



 No. "Trivial to remember" is far from enough. You need to justify why
 there's anything I need to remember in the first place.


 2. Ok, so we can stick a () after get.



 Ok, so it's an arbitrary rule. Why exactly is it necessary?


 * need to remember that set does not take a type like any other function,
 just an identifier



 set(auto v)
 Problem solved.



 Yah, "solved" with more arbitrary syntax. I love this.


 Plus with both of the above, you're seem to be using arguments against a
 specific decicated property syntax as as arguments against dedicated
 property syntaxes in general.


 * need to remember that there is no () after width



 Why in the world would there be? It's not a function.



 Well I don't know what it is, so there might as well be some parens in
 there. It's all arbitrary after all. Syntax upon syntax upon syntax. Why do
 we need it?

 This looks like switch all over again :o).



Some other things to consider.  Here's what Qt's property syntax looks like:

    Q_PROPERTY( type name READ getFunction [WRITE setFunction]
    [RESET resetFunction] [DESIGNABLE bool]
    [SCRIPTABLE bool] [STORED bool] )


So this:
    Q_PROPERTY( QString Id READ getId WRITE setId );

defines a property named "Id" of type QString which you read with
getId() and write with setId().

That's also kinda similar to Python's basic pre-2.4 mechanism (you
write normal functions then mark them as part of a property with a
separate line of code).

The main thing that interests me here is the other stuff in Qt's
props: RESET, DESIGNABLE, SCRIPTABLE, and STORED.

Why does Qt need these and what does that imply for D?

--bb
Jul 27 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 27, 2009 at 2:24 PM, John C<johnch_atms hotmail.com> wrote:

 Andrei Alexandrescu wrote:

 Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:h4kkn3$14pv$1 digitalmars.com...

 But what I want is to come with a new design that adds minimum
 aggravation on the learning programmer. If they know how to define a m=













 they must know how to define a property. None of that property blah { =













 ... set ... } crap is necessary.



 I can't be nice about this: Any programmer who has *any* aggrivation
 learning any even remotely sane property syntax is an idiot, period. Th=










 have to be incompetent to not be able to look at an example like this:

 // Fine, I'll throw DRY away:
 int _width;
 int width
 {
 =A0 =A0get { return _width; }
 =A0 =A0set(v) { _width =3D v; }
 }

 And immediately know exactly how the poroperty syntax works.



 Sure. My point is that with using standard method definition syntax
 there's no need for even looking over an example.



 Which is why Steven Schveighoffer's is suggestion is the most pragmatic s=




 far. You just add a "property" attribute to a regular function definition=




 (And it doesn't look ugly, unlike the opGet_/opSet_ idea.)



+1.
That's really all that's needed.  A simple flag to say "this function
acts like a field".

The other variants go further and try to get rid of some of the
redundancy typical of get/set pairs.  But that part isn't really
necessary even if it might be convenient.

--bb
Jul 27 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 That's why properties are not
 functions.



 This post had a negative effect on me: I now think properties are  
 functions even more than before.



Let me bring you back to the issue at hand:

writefln = "hi";

:)

properties are *implemented* using functions, but both properties and  
function usage should be restricted to disallow bizare code.

Another example:

I've brought up this example before, but I'll summarize the issue.  I  
created a TimeSpan struct for Tango, which represents a span of time.  I  
had static functions to create time spans, and properties to convert time  
spans.  For example:

struct TimeSpan
{
   static TimeSpan seconds(long n); // returns a TimeSpan representing n  
seconds

   ...

   long seconds(); // convert this timespan to seconds
}

So you use it like this:

auto ts = TimeSpan.seconds(5);
assert ts.seconds == 5;

But then I got a bug report one day that this assert fails:

auto ts = TimeSpan.seconds(5);
ts.seconds = 4;
assert(ts.seconds == 4);

What the second line does is create a temporary TimeSpan of 4 seconds, and  
throw it away.

What happened here?  Why did the compiler compile this code at all?  Well,  
because I can't tell the compiler "no, that static seconds function is  
*not* a property", someone tried to use it as one, and then complained it  
didn't work like it should.  Would anyone reading the second line of code,  
knowing it compiles, *not* think "aha! TimeSpan has a way to set it's  
seconds component"?

The "solution" was to rename the static function to fromSeconds, although  
this is still valid code:

ts.fromSeconds = 4;

it doesn't look like it means anything (what's this fromSeconds field?).   
But WTF?  Why do I have to do this kind of shit instead of just telling  
the compiler "this is how you use my object.  Any other uses are invalid.   
End of discussion".

For reference: http://www.dsource.org/projects/tango/ticket/1184

-Steve
Jul 27 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 That's why properties are not
 functions.



 This post had a negative effect on me: I now think properties are 
 functions even more than before.



 Let me bring you back to the issue at hand:
 
 writefln = "hi";
 
 :)



That wart must be eliminated. But the shortcomings of the current design 
are not a proof that we need a specialized facility for what is at the 
end of the day nothing but a notational convenience.


 properties are *implemented* using functions, but both properties and 
 function usage should be restricted to disallow bizare code.



I agree.


 Another example:
 
 I've brought up this example before, but I'll summarize the issue.  I 
 created a TimeSpan struct for Tango, which represents a span of time.  I 
 had static functions to create time spans, and properties to convert 
 time spans.  For example:
 
 struct TimeSpan
 {
   static TimeSpan seconds(long n); // returns a TimeSpan representing n 
 seconds
 
   ...
 
   long seconds(); // convert this timespan to seconds
 }
 
 So you use it like this:
 
 auto ts = TimeSpan.seconds(5);
 assert ts.seconds == 5;
 
 But then I got a bug report one day that this assert fails:
 
 auto ts = TimeSpan.seconds(5);
 ts.seconds = 4;
 assert(ts.seconds == 4);
 
 What the second line does is create a temporary TimeSpan of 4 seconds, 
 and throw it away.
 
 What happened here?  Why did the compiler compile this code at all?  
 Well, because I can't tell the compiler "no, that static seconds 
 function is *not* a property", someone tried to use it as one, and then 
 complained it didn't work like it should.  Would anyone reading the 
 second line of code, knowing it compiles, *not* think "aha! TimeSpan has 
 a way to set it's seconds component"?
 
 The "solution" was to rename the static function to fromSeconds, 
 although this is still valid code:
 
 ts.fromSeconds = 4;
 
 it doesn't look like it means anything (what's this fromSeconds 
 field?).  But WTF?  Why do I have to do this kind of shit instead of 
 just telling the compiler "this is how you use my object.  Any other 
 uses are invalid.  End of discussion".
 
 For reference: http://www.dsource.org/projects/tango/ticket/1184



I agree that that's a wart too that needs to be removed.


Andrei
Jul 27 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 27 Jul 2009 12:16:59 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 That's why properties are not
 functions.



 This post had a negative effect on me: I now think properties are  
 functions even more than before.



  writefln = "hi";
  :)



 That wart must be eliminated. But the shortcomings of the current design  
 are not a proof that we need a specialized facility for what is at the  
 end of the day nothing but a notational convenience.



I personally am OK with any solution that allows me to specify that a  
function is actually a property, thereby restricting the compiler from  
allowing assignment calls with normal functions.

The most straightforward solution I can think of is marking a function  
with a keyword, i.e.:

property int x() {return _x;}
property void x(int n) {_x = n;}

The other syntax suggestions provide different added bonuses, but I think  
all of those bonuses are not as critical as code working as expected.

For example:

- implied hidden storage
- documenting property getters/setters as one entity
- being able to execute a getter during a debug session.

-Steve
Jul 27 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 27 Jul 2009 17:24:06 -0400, John C <johnch_atms hotmail.com> wrote:


 Which is why Steven Schveighoffer's is suggestion is the most pragmatic  
 so far. You just add a "property" attribute to a regular function  
 definition. (And it doesn't look ugly, unlike the opGet_/opSet_ idea.)



I'll note that I wasn't the first to suggest it...  But I do think it's  
the best solution.

-Steve
Jul 27 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 27 Jul 2009 21:14:10 -0400, Rainer Deyke <rainerd eldwood.com>  
wrote:


 Benji Smith wrote:

 For my money, the best solution is a simple "property" keyword as a
 function modifier. Only functions with the "property" modifier would be
 allowed to pose as fields (getters called without parens, setters called
 using assignment syntax). But, in all other respects, they should act
 just like functions.



 I like being able to distinguish between the property itself and its
 setter/getter function.

 For example, let's say 'y' is a property of 'x'.

 z = x.y; // Calls the getter.
 x.y = z; // Calls the setter.
 z = &x.y; // But what's this?  The setter, the getter, or the property
 itself?



This is a general problem with all overloaded functions.  The answer is  
that it's the first one declared.

You can specify it by declaring the type of z before assigning.

I think this might need some attention in general, not just for properties.

-Steve
Jul 28 2009