On 4/27/2011 9:06 AM, David Simcha wrote:
> 
> 
> On Wed, Apr 27, 2011 at 12:00 PM, Steve Schveighoffer <schveiguy at yahoo.com <mailto:schveiguy at yahoo.com>> wrote:
> 
>     I don't want to keep arguing this, but I feel compelled to keep re-iterating:
> 
>     The delegate return problem is nice to solve but is *NOT* the main thing that @property solves.  One can already
>     call the delegate using a double set of parentheses, and it's not common to have a property that returns a delegate.
> 
>     The main problem solved is that one cannot simply use property syntax where it was not intended.  This is the piece
>     that is not yet implemented.
> 
> 
> Again, I just can't justify breaking existing designs for something that's such a non-issue in practice, except in a few straw-man cases where the function in question is poorly named.

I really don't want to get dragged into this discussion, but I feel one point needs to be made...

Strict properties don't break designs.  They break current implementations of that design.  Having strict properties in no way restrict the ability to use the so called fluent programming model.  It just means you can't use the two in the exact same methods, which I argue is exactly the right thing to disallow.

Back to lurk mode, hopefully.