Revised RFC on range design for D2

[sclytrack]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at 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