Overloading property vs. non-property

[Don]

Robert Jacques wrote:
> 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?

Andrei tried to avoid mentioning language features which he hoped would 
change. That's why there's no mention of __traits, for example.