On Sat, 01 Aug 2009 20:48:58 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Sergey Gromov wrote:
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:
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.
That's not "all." To me it's mostly maintainability.
If there is a property 'foo' and you allow to set it both as 'foo = 5'
and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard,
or even impossible for you, the maintainer, to switch from a property
back to a regular field for 'foo'.
If you allow to call function 'bar()' both with and without
parentheses,
and a project is maintained by more than one person, they *will* call it
differently making the source look inconsistent.
Dropping the 'omittable parentheses' thing happens to solve these, and
the delegate return problem, and helps to disambiguate words with
overloaded meanings.
Thanks for these great points. As an additional example, most ranges
define the method
bool empty() { ... }
whereas infinite ranges define the enum
enum bool empty = false;
It follows that if a range user wants to be compatible with finite and
infinite ranges, they always must use no "()". It would be nice if the
range's definition could enforce that.
Andrei
Great points?
Sorry, but all it takes is one person to subclass and overload foo, and
then it can never be turned back into a field. That is, if you're worrying
about maintainability.
As for source code consistency, I view no-(), () and not caring as part
whole code format/variable issue. I mean, code::block has 5 different
layout styles (+custom definitions). What about variable names, hmm?
e/empty/isEmpty/is_empty? I would think any project than can maintain code
consistency of those other issues, they can also manage ()/no-()/mixed.
Hmm... I just had a crazy thought, regarding Andrei's enum bool empty =
false; example. What if in addition to functions as fields (aka
properties) D allowed fields as functions? i.e.
c.foo(5); => c.foo = 5
when method foo doesn't exist.
