@property

[Jonathan M Davis]

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