On Thu, 28 Jan 2010 08:57:15 -0500, Andrei Alexandrescu
<[email protected]> wrote:
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.
Because popFront isn't a property. It doesn't return anything, does it?
A property either fetches a value or sets a value. Defining anything else
as a property is disingenuous, and that was the original problem -- you
could make it look like you were accessing a property when you really
aren't.
popFront should not be a property and should always have parentheses after
it.
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.
You are governed by your personal restrictions and taste. The problem is
that left to their own devices, people will use their own style of calling
functions. Some will always use parentheses even when the function is
supposed to be a property, others will always avoid parentheses when they
can, yet others will be somewhere in between. The end result is you have
code that is not intuitive to you if the author doesn't follow your
style. At least with a property requirement, there is only one style.
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.
the similarity is that an optional specification became required because
it was confusing when you went to use the function how to call it. I
agree the similarity is not 1 to 1, but what I meant to point out is that
people who started with ANSI C (myself included) never missed that
feature. Only those who used the feature would be upset. Likewise, I
started using properties when I learned C# way before I learned D. I
would never miss the optional-parens style of a function that's not a
property because I never really got used to doing it. So do you miss it
because it had true benefits or because you're just used to doing it that
way?
-Steve
