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.
