Sat, 01 Aug 2009 23:36:57 -0400, Robert Jacques wrote: > On Sat, 01 Aug 2009 20:48:58 -0400, Andrei Alexandrescu > <[email protected]> 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.
