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