@property - take it behind the woodshed and shoot it?

[H. S. Teoh]

On Mon, Jan 28, 2013 at 12:22:01AM -0500, Steven Schveighoffer wrote:
[...]
> Disagree.  @property serves a very good purpose -- specifying
> intent.  If the intention of a function is to be used as a dynamic
> field, use @property, otherwise do not.
> 
> Whether or not parentheses should be required on non- at property
> functions, I've given up that struggle.  It's not too terrible, and
> the benefits are difficult to argue against.
> 
> But please, please, PLEASE do not let normal functions be called as
> setters.  If we get rid of @property, we are back to this.  Your
> simple requirements will leave too many functions open to abuse.
> When you take away @property, you take away the expression power of
> an API designer.
> 
> I contend that the issue with @property was that it was
> half-implemented.  When a half-implemented feature is used for 4
> years, it leads to confusion when it doesn't work as specified.
> 
> In other words, we asked you to build a fence.  You built one, but
> didn't finish it, left a gaping hole.  Then you complain about how
> the fence was useless.
> 
> I would be satisfied with Kenji's implementation.  As I understand it:
> 
> @property on a getter would mean implicit calling of the function.
> @property on a setter would mean calling x = y as x(y).
> @property functions could not be called like normal functions.
> Parentheses are optional on normal no-arg functions when used as getters.
> Normal single arg or variadic functions are NOT ALLOWED to be used
> as setters.
> 
> Do it.  I think 99% of the people here would be OK with this.
[...]

+1.


T

-- 
May you live all the days of your life. -- Jonathan Swift