Revised RFC on range design for D2

[Steven Schveighoffer]

"Bill Baxter" wrote
> On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>>> There is no ambiguity either case. You evaluate Stdout.newline. The
>>> evaluation yields a value of some type. Then you evaluate formatln 
>>> against
>>> that value.
>>
>> OK, then tell me what this does:
>>
>> x.y.z();
>>
>> Is y a property/field of x or a function call with no args?  I see a 
>> benefit
>> to being able to understand a line of code without requiring lots of 
>> extra
>> context.  I have to do less lookups of the source of a function or 
>> property.
>
> The problem with this argument is that unless you disallow properties
> altogether, you still won't know whether y is actually a field or a
> call to a property method without looking it up.

Yes, but that is not in question.  A property method is *meant* to be used 
like a field, and so it shouldn't matter whether y is a property or field, 
it should be interchangable.

But if y is not meant to be a property, then it is confusing to read x.y.z() 
and realize that y isn't meant to be used as a property, and might not even 
do what you are expecting.

See the TimeSpan problem that I went through for an example:

http://www.dsource.org/projects/tango/ticket/1184

This problem would never occur if you could not just call any function as a 
property.

-Steve