Revised RFC on range design for D2

[Bruno Medeiros]

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>>> Bill Baxter wrote:
>>>> On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm at gmail.com> wrote:
>>>>> 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.
>>>
>>> So the logic is:
>>>
>>> "A field can be accessed with a.b, but not with a.b(). Therefore if 
>>> someone writes a.b, it may be a field or code, but it someone writes 
>>> a.b() it will always be code. Given that a field is cheap and code 
>>> ranges from cheap to expensive, good style is to have a.b always 
>>> refer to cheap stuff, and a.b() always refer to 
>>> not-expected-to-be-cheap stuff."
>>>
>>> I agree with that logic. It makes for a nice convention. (That 
>>> convention is already broken by the built-in dup and sort, but let 
>>> past mistakes be past mistakes.) My response to that is that concerns 
>>> of keeping the language simple and of facilitating generic code are 
>>> counterarguments that should be weighed in as well.
>>>
>>
>> In what way does that convention/style go against facilitating generic 
>> code?
> 
> A generic function writing obj.symbol cannot work across objects that 
> implement symbol as a computed property vs. a field.
> 
> 
> Andrei

I'm not following. If 'obj.symbol' is syntactically available and is 
valid code, shouldn't the generic function work ok regardless of whether 
'symbol' is a computed property or a field?
I mean, what is even the difference from the status quo?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D