Revised RFC on range design for D2

[Bill Baxter]

On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm at gmail.com> wrote:
> 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.
>>
>> --bb
>
> I think the distinction of with and without () is pretty stylistic, because
> the same argument can even be applied to operator overloading (does a=b
> means pointing the variable a to b, or calling a.opAssign(b)?)
>
> For me, I would use () if the function do modify the object itself.

I think the counter-argument to what I just said is that if properties
had to be declared explicitly then at least we would know that .y is
either a field or else something the designer *intended* to behave
like a property.  Which does tell us something.  It most likely means
that it's not an extremely heavy-weight operation, just a lightweight
accessor with maybe a little logic on top.  That could be wrong, but
in that case it's the class designer's fault for misleading us.

--bb