Function calls

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Jan 28 05:57:15 PST 2010


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



More information about the Digitalmars-d mailing list