Function calls

[Steven Schveighoffer]

On Thu, 28 Jan 2010 08:57:15 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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