Steven Schveighoffer wrote:
On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
But in the case of properties only allowed without parens, functions
require parens, you are defining a rule for the compiler. Think of
the parentheses as an extension of the function name, like punctuation.
But you say no parens means query, parens means action. This is sheer
unchecked convention.
But we already have sheer unchecked convention! I could make a function
called sort that reverses an array.
Of course we do. My point is that there's no need to add gratuitous
mechanisms fostering conventions that go unchecked.
I don't get why it makes any
difference to you that the meaning of parentheses and no parentheses is
used by the author of the function. How is this bad or somehow worse
than what we have now? If you don't trust the author's functions do
what they are named for, don't use his functions and properties.
Well you can trivialize all you want but the matters are different. It's
one thing to have good names, good designs, trusted code etc. and a
whole different thing to define a feature of which entire existence only
serves only an unchecked convention.
Since C was invented, we have had the convention that () means function,
lack of () means property. You are acting like the last 37 years of
programming languages never existed, and this is some "new radical"
convention. D is of C lineage, so using long standing C conventions
should not confuse people.
Well C never had properties that executed code, so following the lineage
is a moot point. C also didn't have a variety of other things, such as
member functions. But we do have now. All I want is to not add undue
burden. To me, it would be a mistake if D defined a special syntax for
defining properties as if they were some big deal, to then not check in
any way that they behave any different than regular functions.
Maybe less confusion, definitely more burden.
The burden is on the author to come up with meaningful function names
already. With real properties, at least that task is easier because you
don't need to add extra context to ensure a word is treated as a verb or
a noun (e.g. 'isEmpty' in order to make sure someone doesn't mistake
'empty' for an action). The compiler enforces the requirement of
property syntax vs. function syntax, so no burden there.
No, you add burden by posing the question, do I want people to call with
parens or without? There's always going to be a gray area and there's
always going to be surprising APIs (see e.g. Daniel Keep's point about
range APIs that must actually do stuff in r.empty). With a uniform
convention, all of these issues vanish.
To clarify: if there was any extra checking by the compiler, any
guarantee that the feature would provide at all, I'd be glad to pay the
price of thinking more when putting together a design. But you want to
define a language feature that allows people to require "()" or not as
they please, and that's all. It's a frivolous detail to be spending time
on when designing an API. I simply don't believe that's good language
design.
Andrei
