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