Robert Jacques wrote:
On Sat, 17 Jul 2010 00:58:58 -0400, dsimcha <dsim...@yahoo.com> 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.
You're impression is correct with regard to D as it currently stands and
the final @property proposal compromise.
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 ()."
Technically, TDPL simply doesn't mention Methods-as-Properties as they
are currently implemented in D.
In the event of a difference between TDPL and DMD, TDPL always wins. The
compiler will have to change.
