Sat, 27 Sep 2008 15:19:01 -0500,
Andrei Alexandrescu wrote:
> My point is that I agree with all concerns you are raising but I am not sure they warrant adding a language feature.

I hoped for some reason that these features could simplify the compiler. Now when I think about it I conclude that I was probably wrong. Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint.

So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy.  The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> Bent Rasmussen wrote:
> >> I think that property function call feature in general adds an unnecessary ambiguity to the language.  I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax.  The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method.  Otherwise code tends to become ambiguous and unreadable.
> >
> > Or abstracted and generic.

For me a property is a RAD feature used in Borland Delphi. Published properties are displayed in the object inspector. (You have private, public, published). If you have some getter routine or setter like in C++, to me those are just methods like any other member function in C++, there is no distinction.

Look at the code in Delphi. GetValue, and SetValue are just plain methods and Value is the property.

 procedure SetValue(const Value: string); virtual;
 function GetValue: string; virtual;
 property Value: string read GetValue write SetValue;

I know D is not a RAD language but a system language, but I think D should consider making the distinction, and providing that distinction with its ru ... well lets say reflection.

Without the reflection there's no need for a different
syntax or notation. We could just use the // syntax.
Like in //setter //getter (lame joke).

Basically a property is what made RAD happen. To me a property is
only a property when other programs know about it.
As for syntax (b = a.dork() or b=a.dork), syntax of how to call
a property is of no real value, it's secondary, its, void,
no real meaning. It is just the time it takes to type ().

I miss Delphi.

http://www.drbob42.com/delphi/property.htm

On Sat, 27 Sep 2008 17:56:42 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Sergey Gromov wrote:
>> In article <gbiqbo$m1e$1@digitalmars.com>, SeeWebsiteForEmail@erdani.org says...
>>> Sergey Gromov wrote:
>>>> In article <gbgu0h$5sq$1@digitalmars.com>, SeeWebsiteForEmail@erdani.org says...
>>>>> Sergey Gromov wrote:
>>>>>> I think that property function call feature in general adds an unnecessary ambiguity to the language.  I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax.  The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method.  Otherwise code tends to become ambiguous and unreadable.
>>>>> Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
>>>> Sorry I may have been unclear.  I'm not against interchangeability between properties and property accessor methods.  I'm against using property accessors as methods, and against using methods as if they were property accessors.  The current situation actually breaks maintainability because after somebody used .length() you cannot replace it with a public variable anymore.  And you cannot replace
>>>>
>>>> public void delegate(int) foo;
>>>>
>>>> with an accessor method because the code 'instance.foo();' will stop working as it used to.
>>> I am a bit confused about terminology. Could you please clarify with examples what you mean, also defining all terms (e.g. what does "property accessor" mean?) Thanks.
>>  Property accessor is a method which is invoked when you syntactically access a data field.  They are called getters and setters in many languages.  In current D, any function or method with zero or one argument is considered a property accessor:
>>  class Foo
>> {
>>   int prop()
>>   {
>>     return field + 1;
>>   }
>>   int prop(int value)
>>   {
>>     return field = value + 3;
>>   }
>>   private int field;
>> }
>>  void useFoo(Foo f)
>> {
>>   auto x = f.prop;
>>   f.prop = 5;
>>    auto y = f.prop();  // also allowed
>>   f.prop(8);  // ditto
>> }
>
> Ok, so far so good.
>
>> The 'prop' family of methods are property accessors in my terminology, and they can be replaced with an actual data field:
>>  class Foo
>> {
>>   int prop;
>> }
>>  void useFoo(Foo f)
>> {
>>   auto x = f.prop;  // fine!
>>   f.prop = 5;  // works
>>    auto y = f.prop();  // Error: function expected
>>   f.prop(8);  // Error: function expected
>> }
>>  You see, properties and methods are *not* interchangeable in current D.  Therefore your correct thesis:
>>
>>>>> Experience with other languages has shown that using identical syntax for genuine member access and member function access helps maintainability because it allows a type implementer to switch back and forth between implementing a property as a direct member or as a function, transparently to that type's use.
>>  does not apply to D.
>
> It does apply, just only one direction. From the above, it looks like a good guideline is to always use the syntax:
>
> auto x = f.prop;
> f.prop = x;
>
> because it is more general. And indeed, consider something as innocuous as the empty member for a range. Some here said I should write range.empty() throughout. But that, aside from wrist and eye pain, precludes infinite ranges from implementing empty as simple as:
>
> struct Generator {
>      ...
>      enum empty = false;
> }
>
> But if that implementation were allowed, that would be a boon for generic code because it can easily detect infinite ranges statically.
>
>> Here's another example:
>>  class Bar
>> {
>>   int delegate() meth;
>> }
>>  int useBar(Bar b)
>> {
>>   return b.meth();
>> }
>>  Can you replace 'meth' with a getter?
>>  class Bar
>> {
>>   int delegate() meth()
>>   {
>>     return {return 5;};
>>   }
>>  }
>>  int useBar(Bar b)
>> {
>>   return b.meth();  // Error: cannot implicitly convert expression
>>   // (b.meth()) of type int delegate() to int
>> }
>>  No you cannot.  But you could be able to do all those nice things if you had an explicit syntax for getters and setters:
>>  class Foo
>> {
>>   property int prop() {...}
>>   property int prop(int value) {...}
>>   property int prop(int v, char c) {...} // syntax error, 2 arguments
>>   property int delegate() meth() {...}
>> }
>
> I agree. But there's a simpler solution:
>
> int useBar(Bar crystal)
> {
>    return (crystal.meth)();
> }
>
> Looks a bit uneasy on the eye? I agree. But count the lines you use member delegates in; then count the lines you use non-delegate member access; divide the first by the second; multiply by 100; and... is that worth a language feature?
>

It is. A duality like this is bad for language. Should you write foo.bar or foo.bar()?
If the former, as you insist, then why not force it? If the latter, then it is not a property anymore. It is a language hack right now!

Sergey's proposal is great because it is simple, expressive, sound and it removes the ambiguities that are present now.

> you didn't like to type parentheses,

I think that's a valid concern. C/C++ code is full of "()"-pairs and they make the code harder to type and more difficult to parse (for me, that is).

L. 

Sergey Gromov wrote:
> Sat, 27 Sep 2008 15:19:01 -0500,
> Andrei Alexandrescu wrote:
>> My point is that I agree with all concerns you are raising but I am not
>> sure they warrant adding a language feature.
> 
> I hoped for some reason that these features could simplify the compiler.  Now when I think about it I conclude that I was probably wrong.  Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint.
> 
> So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy.  The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.

Very wise words.

I think we all agree that there are some annoyances related to the whole property business, among which the main one is:

writeln = 4;

That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.

How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?


Andrei

Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> Sat, 27 Sep 2008 15:19:01 -0500,
>> Andrei Alexandrescu wrote:
>>> My point is that I agree with all concerns you are raising but I am not
>>> sure they warrant adding a language feature.
>>
>> I hoped for some reason that these features could simplify the compiler.  Now when I think about it I conclude that I was probably wrong.  Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint.
>>
>> So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy.  The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
> 
> Very wise words.
> 
> I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
> 
> writeln = 4;
> 
> That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
> 
> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?

Just trying to think of something that could be easily parsed...

void foo(char t)!={ /*do something with t*/}
void bar(char t)  { /*do something with t*/}

void main() {
    foo('t'); // okay
    foo='t';  // not okay because of the "!="
    bar('t'); // okay
    bar='t';  //  okay
}

My thinking is that it doesn't break existing code.  One could change the order to precede the argument list, but I don't like that as much because it becomes ambiguous when used in conjunction with templates.

Just my $0.02.

> For me a property is a RAD feature used in Borland Delphi. Published properties
> are displayed in the object inspector. (You have private, public, published). If
> you have some getter routine or setter like in C++, to me those are just methods
> like any other member function in C++, there is no distinction.
> Look at the code in Delphi. GetValue, and SetValue are just plain methods and
> Value is the property.
>  procedure SetValue(const Value: string); virtual;
>  function GetValue: string; virtual;
>  property Value: string read GetValue write SetValue;
> I know D is not a RAD language but a system language, but I think D should
> consider making the distinction, and providing that distinction with its ru ...
> well lets say reflection.
> Without the reflection there's no need for a different
> syntax or notation. We could just use the // syntax.
> Like in //setter //getter (lame joke).
> Basically a property is what made RAD happen. To me a property is
> only a property when other programs know about it.
> As for syntax (b = a.dork() or b=a.dork), syntax of how to call
> a property is of no real value, it's secondary, its, void,
> no real meaning. It is just the time it takes to type ().
> I miss Delphi.
> http://www.drbob42.com/delphi/property.htm


Just in case things got lost in translation, ...
I actually want properties, and a different syntax, like the C# one looks good.

Sat, 27 Sep 2008 23:08:43 -0700,
Chris R. Miller wrote:
> Andrei Alexandrescu wrote:
> > I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
> > 
> > writeln = 4;
> > 
> > That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
> > 
> > How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?
> 
> Just trying to think of something that could be easily parsed...
> 
> void foo(char t)!={ /*do something with t*/}
> void bar(char t)  { /*do something with t*/}
> 
> void main() {
>      foo('t'); // okay
>      foo='t';  // not okay because of the "!="
>      bar('t'); // okay
>      bar='t';  //  okay
> }
> 
> My thinking is that it doesn't break existing code.  One could change the order to precede the argument list, but I don't like that as much because it becomes ambiguous when used in conjunction with templates.

I cannot see how trickery with an existing syntax is less a feature than a new keyword.

Sergey Gromov wrote:
> Sat, 27 Sep 2008 23:08:43 -0700,
> Chris R. Miller wrote:
>> Andrei Alexandrescu wrote:
>>> I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
>>>
>>> writeln = 4;
>>>
>>> That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
>>>
>>> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?
>> Just trying to think of something that could be easily parsed...
>>
>> void foo(char t)!={ /*do something with t*/}
>> void bar(char t)  { /*do something with t*/}
>>
>> void main() {
>>      foo('t'); // okay
>>      foo='t';  // not okay because of the "!="
>>      bar('t'); // okay
>>      bar='t';  //  okay
>> }
>>
>> My thinking is that it doesn't break existing code.  One could change the order to precede the argument list, but I don't like that as much because it becomes ambiguous when used in conjunction with templates.
> 
> I cannot see how trickery with an existing syntax is less a feature than a new keyword.

Awe, but making the syntax more complex makes the code look so much more unfriendly ;-)

My thought process hadn't even touched upon the idea of adding another keyword.  But then what would the keyword be?  "noeq"?  "noprop"? "propless"?  "muffin"?  (I vote for muffin!)  ;-)

Andrei Alexandrescu wrote:

> I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
> 
> writeln = 4;
> 
> That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
> 
> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?

That seems like a bad idea if it allows a forgetful/lazy/overworked library writer to cause users to be unable to use property syntax in natural cases. I'd say explicit forbidding of property syntax is a better idea.

Based on some people's view of properties, allowing property get syntax for pure functions would make a lot of sense.  Others would hate that.  I'm not sure if restricting users would be all that popular.  It may be better placed in some kind of lint tool.