Overloading property vs. non-property

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Chad J (chadjoan at __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 non- at 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 pro- at 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