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
