Overloading property vs. non-property

[Don]

Robert Jacques wrote:
> On Sat, 17 Jul 2010 00:58:58 -0400, dsimcha <dsimcha at yahoo.com> 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.
> 
> 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.