Revised RFC on range design for D2

[Bruno Medeiros]

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> 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?
> 
> What I meant is very simple. Generic code benefits from unified syntax.
> Going with one convention across the board would make generic code
> simpler. Going with the convention that expensive stuff is with "()" and 
> cheap stuff is without "()" differentiates usage.
> 

Ah, got it now. I misunderstood the original "So the logic is:" post.
But I don't think the idea (from Bill and others) was to omit "()" for 
all cheap stuff functions, but only for those explicitly made to behave 
as properties/fields. That way would not hurt generic code, it would be 
the same as the status quo in that regard.


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