Overloading property vs. non-property

[Robert Jacques]

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.