On Sat, 17 Jul 2010 02:38:20 -0400, Don <[email protected]> wrote:
Robert Jacques wrote:
On Sat, 17 Jul 2010 00:58:58 -0400, dsimcha <[email protected]> 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.
Before reading TDPL I'd had agreed with you 100%. Now, I find that TDPL is
either ambiguous or anticipatory in a small number of cases. For example,
Functions-as-Methods get more exposure than @property, but no limitations
are mentioned nor are there any generalized examples presented. So is the
feature limited to arrays (current DMD) or available to all types
(Slide-ware from the D conference)? Clear and the removal of delete got a
solid paragraph of explanation and rational, but recent discussions have
highlighted issues. And while I believe these issues to be solvable, as
the devil is always in the details, this might not always be the case
where TDPL anticipates DMD. By contrast, @property literally gets 1 line
of text, 2 off-hand code uses and Methods-as-Properties is never
mentioned. So was Methods-as-Properties not mentioned because it was
dropped from the spec or because TDPL is downright laconic with regard to
properties in general?
