@property - take it behind the woodshed and shoot it?

[Dmitry Olshansky]

26-Jan-2013 09:04, deadalnix пишет:
> On Friday, 25 January 2013 at 19:59:59 UTC, Andrei Alexandrescu wrote:
>> 1. Syntactic and semantic implications of properties that return
>> callable entities
>>
>
> I don't understand why this is a special case in the first place. It
> should behave just like a variable of the same type, period.
>
>> C has no methods so the syntax "object.method" does not apply to it.
>> In C++, "object.method" is probably the oddest construct in the entire
>> language: it returns a type that exists but has no name, is not
>> expressible syntactically, is not first class (one can't assign
>> "object.method" to a variable), and has only two allowed operations:
>> take address or apply the function call operator "()". Various C++
>> implementations have extensions that fix this.
>>
>> Both Walter and I consider these serious lapses in language design.
>> Two of the most accessible elements of syntax do things of
>> considerably low interest and use. I hope I now clarified why I have a
>> dim view of arguments that - implicitly or explicitly - assume the C
>> or C++ behavior in this area is an example to follow on technical
>> grounds. (Clearly, familiarity is a much better argument.)
>>
>
> Javascript or C# have solved that issue with C like language nicely.
> That is why I propose to do the same here (and considering how much C#
> has been mentioned here, it sound like a serious option). I know that
> Javascript is a poorly designed language, but on that very specific
> topic most people agree that was has been done at the time was pure genius.
>
> It removes the weird C/C++ object that have no expressible type, and
> simplify the situation. Additional benefice is that funName now behave
> the same in all situation, which is also a simplification of the situation.
>
>> 2. I have tried to add @property appropriately in Phobos, in
>> particular for ranges:
>>
>> struct SomeRange {
>>   @property bool empty();
>>   @property ref T front();
>>   void popFront();
>> }
>>
>> There's more "@property" to be seen with "save" and "back".
>> Subjectively that just didn't work well for me. It adds clutter to an
>> otherwise simple and straightforward API, and penalizes usage for
>> benefits that I could never reap. I understand how some people are
>> glad to put that in everywhere, and find meaning in requiring parens
>> with popFront and popBack but not the others. Yet for me it was
>> liberating (see 1 above too) I could just write "r.popFront" without
>> the parens and have it do its deed. It is the right semantics for a
>> simple syntax.
>>
>
> If you ask me, I think property have been abused in range design. Many
> ranges properties really shouldn't be properties.
>
> Additionally, this kind of boilerplate can easily be written by
> automated tools. Java or C# are very verbose, but it is very efficient
> to write program in them, as the tooling to a great job for you.
>

Automated tooling is admitting a defeat if we talk about expressive 
languages. Java was designed with automatic code manipulation in mind 
and even with todays proliferation of generators it's a pain to work with.

TL;DR code is written once and read many times.

-- 
Dmitry Olshansky