www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: property syntax strawman

reply Sjoerd van Leent <svanleent gmail.com> writes:
Andrei Alexandrescu Wrote:

 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h53g3i$elk$1 digitalmars.com...
   bool empty { ... }
   void empty=(bool b) { ... }

 What do you think?

I think that if D starts to make a habit of aping the ugly C++ approach to adding new features (as this does), then we may as well just use C++.

Let's not forget that C++ got very conservative about adding keywords after a keyword spree (class that is essentially same as struct, namespace, xyz_cast, oh yes typename, and, or, not plus other useful names that I probably forgot). We don't want to get there. Andrei

I understand your point of view, but I am afraid that using an awkward syntax makes things difficult to understand. However, I could certainly live with the current proposal. But this has to do that I'm not afraid of symbolic ways to achieve something. Others might find it more difficult. I think that a setter and a getter are two different things, but I would avoid to have an inconsistent property, such as setting an int and getting a bool, or something similar. Perhaps a compiler check could intercept? But I think I can do it with the keywords that we already have in our possession: bool in empty { } bool out empty { } Although perhaps this could be argued against, as in and out are used for contract programming. But this clearly is a different use.
Aug 04 2009
parent reply John C <johnch_atms hotmail.com> writes:
Sjoerd van Leent wrote:
 Andrei Alexandrescu Wrote:
 
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h53g3i$elk$1 digitalmars.com...
   bool empty { ... }
   void empty=(bool b) { ... }

 What do you think?

adding new features (as this does), then we may as well just use C++.

after a keyword spree (class that is essentially same as struct, namespace, xyz_cast, oh yes typename, and, or, not plus other useful names that I probably forgot). We don't want to get there. Andrei

I understand your point of view, but I am afraid that using an awkward syntax makes things difficult to understand. However, I could certainly live with the current proposal. But this has to do that I'm not afraid of symbolic ways to achieve something. Others might find it more difficult. I think that a setter and a getter are two different things, but I would avoid to have an inconsistent property, such as setting an int and getting a bool, or something similar. Perhaps a compiler check could intercept? But I think I can do it with the keywords that we already have in our possession: bool in empty { } bool out empty { } Although perhaps this could be argued against, as in and out are used for contract programming. But this clearly is a different use.

in and out are also used for function parameters, remember.
Aug 04 2009
parent Sjoerd van Leent <svanleent gmail.com> writes:
John C Wrote:

 Sjoerd van Leent wrote:
 Andrei Alexandrescu Wrote:
 
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h53g3i$elk$1 digitalmars.com...
   bool empty { ... }
   void empty=(bool b) { ... }

 What do you think?

adding new features (as this does), then we may as well just use C++.

after a keyword spree (class that is essentially same as struct, namespace, xyz_cast, oh yes typename, and, or, not plus other useful names that I probably forgot). We don't want to get there. Andrei

I understand your point of view, but I am afraid that using an awkward syntax makes things difficult to understand. However, I could certainly live with the current proposal. But this has to do that I'm not afraid of symbolic ways to achieve something. Others might find it more difficult. I think that a setter and a getter are two different things, but I would avoid to have an inconsistent property, such as setting an int and getting a bool, or something similar. Perhaps a compiler check could intercept? But I think I can do it with the keywords that we already have in our possession: bool in empty { } bool out empty { } Although perhaps this could be argued against, as in and out are used for contract programming. But this clearly is a different use.

in and out are also used for function parameters, remember.

Yes, but does this create a conflict in this case? It is clearly syntactically different from a function parameter. Perhaps we could also do something like: bool(in) empty { ... = __in; } bool(out) empty { return ...; } I am just trying to think of a variety of possible options. Perhaps for indexes we could use: bool(in) empty(int index) { ...[index] = __in; } bool(out) empty(int index) { return ...[index]; } Just a few thoughts.
Aug 04 2009