Using ()s in @property functions

[Robert Jacques]

On Tue, 29 Jun 2010 01:38:45 -0400, Nick Sabalausky <a at a.a> wrote:
> "Robert Jacques" <sandford at jhu.edu> wrote in message
[snip]
>> So... If we allow properties to be called using () syntax, we have  
>> corner
>> case ambiguities. And if we don't allow properties to be called using ()
>> syntax, we have corner case ambiguities and a minor loss of function
>> (because one ambiguity can't be expressed). Add in Andrei's posts about
>> the difficulty in deciding what methods should and shouldn't be
>> properties, and the more it seems that the real world experience with
>> properties is indicating that @property is a mis-feature that should be
>> dropped from the language.
>
> Hell no. It's far better than what we had before, and far better than  
> just
> simply not having properties. I wouldn't mind improvements, but as for
> ditching it: there's a baby in that bathwater.
>

What baby? @property was introduced solely to clarify the ambiguity of the  
corner case of returning a zero-argument delegate from a method. That's  
it. Methods-as-properties existed long before the @property was proposed.  
(I'm not suggesting in any way that methods-as-properties should be thrown  
out, because that really would be throwing the baby out with the bath  
water.)

P.S. The other reason for introducing the @property was to allow a library  
writer to force certain coding standards on the library users. Some like  
this, some hate this. My count had a con from every pro, but not a pro for  
every con. However, the pro-less cons were mostly mitigated by leaving in  
methods-as-properties, making the final verdict one of those agree to  
disagree compromises.