And so on. C++ extended C to use the same syntax for method calls:
person.age() or person.getAge()
Languages like Eiffel, Ruby, or Fan that treat all method calls as abstract messages don't distinguish between field access and method calls.
Anyway, then we have array or hashtable access syntax, a different kind of membership:
properties["background"]mean the same thing. There's some nicety to that.
But I'm working through a series of issues that will eventually get tangled. First, I need to go back to C. I can abstract member access there, too:
moveTo(pen, x, y)
I'll pretend to have those namespaced for the moment (since otherwise in C they'd have uglier names), and if I have dynamic dispatch on the first (or more) arguments, this syntax could have the same meaning as virtual methods in C++ or Java or whatnot. For example, MATLAB can do OOP method dispatch with standard function call syntax.
So the syntax question becomes do you like nested function calls or postfix member dot access? I think the postfix (or somewhat infix) C++ style is easier to understand:
The chain is just easier to read. And apparently the C# folks thought so enough that they introduced extension methods. A semi-complicated way of allowing dot chain syntax. Why not just make a language such that both syntaxes are equivalent?
One reservation. Here's that tangle to which I was referring. Lets look at arrays again. Why do we really need a separate array access syntax vs. function call syntax? An array is just a function that hardcodes the responses, in one way of looking at it. So, like Scala or MATLAB, we could make them the same:
So, it tells member that array/hashtable lookup should best be separate syntax from function calls. I like it ('persons') as shorthand for notions like 'persons.get(4)'. I think otherwise the unification of concepts leads to entanglement.
At least, I haven't worked out another solution I like better.