new DIP5: Properties 2

Steven Schveighoffer schveiguy at yahoo.com
Fri Jul 31 10:51:43 PDT 2009


On Fri, 31 Jul 2009 13:34:13 -0400, Marianne Gagnon <auria.mg at gmail.com>  
wrote:

>
>>
>> I think the poll might have been skewed due to context (forget my
>> newsgroup poll, that was worthy of an abortion, but I also didn't mean  
>> to
>> submit it :), I'm talking about Ary's)
>>
>> The question was asked, what do you think this code means.  In the  
>> context
>> of D, where you know a symbol without parentheses can mean either a
>> function or a property/field, I'm certain there were several respondants
>> who didn't understand it was asking what they think is best, not *what D
>> currently does*.  Ask that same questions to C++ developers and see what
>> you get...
>>
>> It's hard to phrase the question properly without bias to a group of
>> people who already know the current behavior.  Maybe something like:
>>
>> Assume the D programming language required parentheses for normal
>> parameter-less functions, and required no parentheses for parameter-less
>> functions that returned a property.  For example, the following code
>> should imply a getter for a filter inside x:
>>
>>      auto tmp = x.filter;
>>
>> And the following code should imply performing a filtering action using  
>> x,
>> returning the result:
>>
>>      auto tmp = x.filter();
>>
>> Do you think it's worth adding such a capability, given that you will  
>> then
>> no longer be able to call ordinary parameter-less functions without
>> parentheses, an author of a property function must properly indicate  
>> that
>> the function is a property, and the compiler must trust the author for
>> this implication?
>>
>
>
> IMP, the parenthesis thing is not about parameters vs function. I think  
> the question is about whether the function can modify my object or not.
>
> e.g. if I call
>
> foo = object.x;
>
> I assume 'object' was not modified. But if x can be like a function,  
> disguised as a parameter, I can modify my object without knowing.
>
> In C++, I'd say this behaviour is ok for 'const' functions. Now I  
> haven't taken the time to study D constness, so I can't readily tell  
> what is the direct equivalent, but I guess you understand what I mean.
>
> In short, IMO everything that can modify my object should require () to  
> stress that this is an action with possible side effects, not merely a  
> getter.

Hm... this is somewhat similar to const, be we already have const in D.

I think you and I or on the same page -- parentheses implies action, no  
parentheses implies no action (and therefore, no change to the object).   
However, I can envision properties that do take actions (such as logging)  
and may even change the object (such as caching), and functions that  
perform actions but do not modify the object.  I wouldn't say modification  
of the object is a direct 1-to-1 mapping with parens or lack of parens,  
but I'd definitely say that lack of parens implies no "public"  
modification.

However, none of this would be enforcible via the compiler.  For that, we  
have const.  A const property would make loads of sense, but  
unfortunately, it modifies the contract you have with the object members  
when calling it (see DIP2  
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2).

So to sum up, with this feature lack of parentheses would imply no action,  
but would not be enforced.  However, it would be considered incorrect  
logic if the rule was not followed, similar to naming your functions  
something other than what they do.

-Steve



More information about the Digitalmars-d mailing list