Steven Schveighoffer wrote:
1. Choosing between including @property or not is rare. Most cases are obvious. If you worked with a language that requires property notation (i.e. C#) this would not be as big an issue for you.
I need to put it for all front() and empty() declarations. By the way I decided that popFront() is not a property. I don't know why.
2. Defining @property on functions you wish to call as properties can be done all at once, enclosing all properties in a @property { } block. No need to "litter" all your code with that. Furthermore, function signature 'documentation' is not as littering as you think. Verbosity at definition is not as cumbersome as verbosity at the call site. In other words, the extra litter at definition time pays huge dividends in clarity at the call site, and is not a constant annoyance (you only define things once).
OK. The problem is, I was already enjoying clarity at the call site. So for me the whole @property thing has a much less appeal than it might. I do appreciate that @property eliminates ambiguities in corner cases.
I'm sure C developers who were used to omitting prototypes were equally miffed when it became required.
That situation is different. There's only one possible prototype a function can have. With @property, it's anyone's guess.
Andrei
