property syntax strawman

[Robert Jacques]

On Mon, 03 Aug 2009 11:57:40 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2009-08-03 10:39:17 -0400, "Robert Jacques" <sandford at jhu.edu> said:
>
>> 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.
>
> Interesting remark. You're right of course about the transform example  
> is much clearer in context. I'll conceed that point. But take note you  
> let the user of the API do the disambiguation instead of the designer  
> who wrote the function in the first place. I believe the later is better  
> placed to decide. That said, it's rather a minor point in my opinion.
>
> I'm more concerned by the ambiguity when returning callable objects or  
> delegates when functions have omittable parentheses.
>

I believe in a systems language, the default should be to user choice.  
That said, having a way for an api designer to enforce a particular usage,  
isn't necessarily bad thing either. The lack of an either-or/flexible  
option is, in my opinion, a flaw in all of the proposals so far.