Robert Jacques wrote:
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?
Andrei tried to avoid mentioning language features which he hoped would
change. That's why there's no mention of __traits, for example.
