new DIP5: Properties 2

[Robert Jacques]

On Sat, 01 Aug 2009 20:48:58 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at 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.