On Mon, 03 Aug 2009 11:57:40 -0400, Michel Fortin
<[email protected]> wrote:
On 2009-08-03 10:39:17 -0400, "Robert Jacques" <[email protected]> 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.
