Overloading property vs. non-property

[Robert Jacques]

On Sat, 17 Jul 2010 02:38:20 -0400, Don <nospam at nospam.com> wrote:

> 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.

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?