new DIP5: Properties 2

[Sergey Gromov]

Sat, 01 Aug 2009 23:36:57 -0400, Robert Jacques wrote:

> 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
> 
> 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.

Yes, I agree, properties are still not fields, and subtle differences in
behavior may lead to problems when switching implementation.  One can
overload a getter, or take an address of a setter, or pass a field by
reference.

Though the less such differences exist, the less bugs you're going to
cause in user code when actually switching.  We can even avoid some of
these potential problems:

*  User cannot overload a property in a final class, or when getter and
setter are declared final.  Therefore it's up to an interface designer
whether they want to allow overloading

*  Taking a getter/setter address should not be allowed, at all

*  Passing a property by reference should only work for ref-returning
getters, and produce a nice compile-time error otherwise

If the last two were implemented then we'd be left with only one gotcha
which manifests itself at compile time, is trivial to fix, and may even
be resolved by compiler in the future---see discussions about functions
returning structs.

> 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.

This is exactly Nick's point: you have to establish yet another
arbitrary convention instead of relying on the language rules.  Sure
most of us are used to obeying such conventions but it would be better
not to compilcate them even more.