Revised RFC on range design for D2

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Oct 2 06:24:25 PDT 2008


Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> 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.
>>
>> 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


More information about the Digitalmars-d-announce mailing list