property syntax strawman

[Robert Jacques]

On Mon, 03 Aug 2009 07:04:52 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2009-08-02 23:19:50 -0400, "Robert Jacques" <sandford at jhu.edu> said:
>
>> On Sun, 02 Aug 2009 20:53:35 -0400, Michel Fortin   
>> <michel.fortin at michelf.com> wrote:
>>
>>> On 2009-08-02 20:18:51 -0400, "Robert Jacques" <sandford at jhu.edu> said:
>>>
>>>> I also like the idea of omitting parenthesis for functions with no    
>>>> argument.
>>>  I like it too. But the problem with the current approach D are:
>>>  1. A syntax that permits function to be called both without and with   
>>> empty parenthesis creates ambiguities when it returns a callable type  
>>> (a  delegate or an object with an opCall member).
>>>  2. We want properties to be nouns, and actions to be verbs. In  
>>> english a  lot of words are both nouns and verbs, which makes it  
>>> impractical to  distinguish a property from a function by its name  
>>> alone.
>>>  Solving 1 involves having a way to say functions that can and must  
>>> be  called without parenthesis. Unless we want to force all functions  
>>> with  no parameter to be called without "()", we must have some kind  
>>> of flag  to tell us that a function expects or does not expect "()".
>>>  Solving 2 involves making a difference in the call syntax between   
>>> property and action functions. Since the idea behind a property is to   
>>> mimic a field, it follows that the best differentiator for properties  
>>> is  the lack of parenthesis.
>>>  I'd be glad too if we could continue to skip parenthesis for calls  
>>> to  functions with no arguments, but I think fixing the two problems  
>>> above  is more important.
>>>
>>  I agree 1) is an issue, but I view it as a corner case. (I use  
>> zero/one  arg functions all the time and make use of the 'property'  
>> syntax left  right and center, but I've never run into the opCall  
>> problem) It would be  nice if it were fixed, but we may be cutting off  
>> the nose to spite the  face, as it were. (Or alternatively, taking the  
>> scientific instead of  engineering approach)
>>  Problem 2) I think is a major logical flaw: a property is a function.  
>> So I  see no need to distinguish between the two. Properties, in fact,  
>> can be a  very expensive functions that takes locks/do database  
>> lock-up/etc. So  making syntax changes that make 'properties' look  
>> cheap and 'functions'  look expensive is worse than what we have today.  
>> Today, at least, everyone  knows that no parenthesis doesn't mean  
>> necessarily cheap O(1) operation.
>
> And I agree with you: properties are functions. But problem number 2  
> isn't about whether properties are functions or not. It's about the  
> meaning of a name. Say you have a "transform" function, you'll have some  
> expectations about what it does based on the name. So I ask you: is a  
> "transform" function an *action* (a verb) in the sense that it applies  
> some transformation to an object, or is it a *property* (a noun or  
> adjective) in the sense that it returns something like an affine  
> transform associated with an object? The semantics of the two are  
> completely different, yet they share the same name.
>
> The real ambiguity here is the English language, were many nouns and  
> adjectives are also verbs. We could switch to a natural language that  
> does not have this problem for function name -- say French: "transform"  
> becomes "transformer" (action, verb) or "transformation" (property,  
> noun); "empty" becomes "vider" (action, verb) or "vide" (property,  
> adjective) -- but that doesn't seem like a very practical option.
>
> So, beside switching to a non-English language, we have two other  
> options. First we could write a guideline saying properties (nouns and  
> adjectives) should start with some prefix. I tried it[1]. I couldn't  
> come with anything sane that works for non-boolean properties. In  
> addition, most people don't read guidelines, and educating people to  
> write "is", "has" or a modal verb in front of boolean properties would  
> be a major effort. It works in Objective-C, but Objective-C function  
> naming conventions are very different.
>
>  [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines
>
> So the only option left, assuming we still want to solve the problem, is  
> to introduce a formal syntax in D to distinguish properties (nouns and  
> adjectives) from actions (verbs). A natural fit for that at the call  
> site is to use the syntax without tailing empty parenthesis for  
> properties, mimicking fields, and use the inherited function syntax from  
> C-derived languages for actions. Choosing the right syntax for property  
> definitions is a greater challenge since we want a simple syntax that  
> helps people make the right choice depending on wether they want a  
> property or an action, but we  (Andrei, me, some others) don't want to  
> deviate too much from a regular function either.
>
> As for whether properties should be cheap (not perform anything  
> heavyweight) or not, that's another debate result in a guideline.
>

Thank you for the very elegant expression of the problem and for posting  
the programming guidelines wiki. My criticism is that you're defining your  
context to narrowly. A function/property/field isn't just defined by it's  
name, but also by it's type and the context it's in. A 'transform' of type  
void or typeof(this) is obviously an action, while a 'transform' of type  
Matrix might be a coordinate frame. The object's type also conveys context  
information; a 'transform' on an autobot might be an action, while a  
'transform' on it's 3D model might be a coordinate frame. Even if you  
don't know the return type off the top of you're head (i.e. you're doing a  
code review), 'transform;' or 'object.transform;' are obviously actions  
while 'auto a = object.transform;' or 'object.transform = a' is a noun.  
English solves it language ambiguity issues with context, so why can't the  
same solution apply to programming languages? Sure, pathological examples  
are possible, just as they're possible in English, but that's no reason to  
switch to a different language.