My apologies if this ends up being sent twice. I'm having problems with my client at the moment.
On Thursday, June 24, 2010 14:15:22 Pelle wrote: > On 06/24/2010 10:43 PM, Jonathan M Davis wrote: > > Other than legacy, code I see 0 benefit to allowing non-property > > functions to be called as if they were properties. They aren't > > properties and shouldn't be treated that way. Now, a programmer is free > > to use @property as they please in the code and can abuse it just like > > any other part of the language, but the whole point of being able to > > call functions without parens is in order to have property syntax for > > properties. I, for one, do not think that non-property functions > > should be able to be called as if they were properties. > > > > - Jonathan M Davis > > The problem lies within the definition of what a property is and is not, > as well as can and cannot be. > > A benefit to the current situation is that fewer parentheses means less > line noise, and prettier code. I really didn't think that there was much of question on that, but I guess that I was wrong. Everywhere that I've seen properties discussed, properties are values that could be either public member variables or have private member variables with getters and setters - the one extension being that that rather than having the property being stored in a member variable, it could be calculated (such as empty being calculated from size rather than stored separately). If it doesn't make sense for the property to be replaced with a getter function (if it's a readable property) and/or setter function (if it's a writeable property), then it's not a property. writeln() isn't a property because it makes no sense to replace it with a getter or setter. The same goes for save() or popFront() on a range. However, things like length() and empty() are properties because they could be replaced with functions like getLength() and isEmpty(). I really think that the main problem here is that any function that looked like property could previously be called like a property. Now, with the @property syntax, it becomes a matter of choice of the programmer. They are free to label properties with @property or mislabel non-properties with @property. There probably are a few functions out there where it would be unclear as to whether they should be a property or not, but for the most part, I don't see why there should be any confusion. Properties are basically a way to make getters and setters look like public member variables. - Jonathan M Davis
