dsimcha wrote:
== Quote from Chad J (chadj...@__spam.is.bad__gmail.com)'s article
On 07/15/2010 09:16 AM, dsimcha wrote:
Once property syntax is fully enforced (not necessarily recommended) will it
be possible to overload properties against non-properties? My use case is
that I'm thinking about API improvements for my dflplot lib and one thing that
I would really like is to give a fluent interface to everything to further cut
back on the amount of boilerplate needed to generate simple plots. For example:
Histogram(someData, 10)
.barColor(getColor(255, 0, 0))
.histType(HistType.Probability)
.toFigure.title("A Histogram")
.xLabel("Stuff").showAsMain();
The problem is that I also want things like barColor and title to be settable
via normal property syntax, using the equals sign. Right now, this "just
works" because D's current non-analness about enforcing @property-ness is
awesome 99% of the time even if it leads to a few weird corner cases. Will
there be a way to express such an interface to be provided (calling a setter
as either a member function or a property at the user's choice) once @property
is fully implemented?
Wasn't this going to be handled by normal n...@property functions?
I was under the impression that normal functions/methods with no
arguments would still allow omission of parentheses and the assignments
would still be rewritten to 1-arg calls. As long as the semantics of it
are handled correctly then that syntax will be safe; it just has to do
what the programmer /expects/.
The @property syntax can resolve some ambiguities, so they are quite
useful if you want to say, return a zero-argument delegate from a
property.
This is what I'd vote for, but it's not what TDPL says. Page 156:
"In particular 'property' is recognized by the compiler and signals the fact
that
the function bearing such an attribute must be called without the trailing ()."
At the time of writing, there had recently been a large discussion of
properties in this newsgroup. Some good arguments had been made, mainly
the ambiguity of functions that return delegates. Plus generally the
participants to that discussion had taken a very strong p...@property
stance (I was one of the few who disagreed and hoped a simpler solution
could be found). So the text is written under the assumption that
ultimately "()" must be present unless @property was used in the
definition. (And if it was used, "()" would be disallowed, hence the
"must" in the quote above.) At the same time, the feature was not yet
present in the compiler, so I didn't want to describe it in more detail.
Andrei
