Function calls

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:hjtet5$111d$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
>> news:hjtcbd$r0a$1 at digitalmars.com...
>>> Nick Sabalausky wrote:
>>>> And yes, I already pointed out that would make it a no-argument 
>>>> function. And that's precisely my point. If we accept that it's bad to 
>>>> paint a car via its "@property" wheel, then how can we possibly accept 
>>>> this to not be just as bad?:
>>>>
>>>> auto car = new Car();
>>>> auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
>>>> wheel.paintTheCar();
>>> Because a function doesn't attempt to emulate a field.
>>>
>>
>> D's approach to properties *forces* functions to emulate fields.
>
> Unfortunately not. It forces nothing. That's my problem with the feature - 
> it's nothing more than fostering a convention.
>

A programming language *is* a set of enforced conventions. When something 
either can't be enforced mechanically (ex: accurate and meaningful variable 
names), or has real practical value in not having an enforced convention 
(ex: user-definable variable names, free-form whitespace, underscores in 
numeric literals), that's when it's left to the users to make up their own 
arbitrary and likely-conflicting conventions. Arbitrary freedoms just for 
the sake of it: great in real life, lousy in a programming language.

If we don't enforce the convention of (non-property) functions being called 
with parens, the only things gained besides that useless "arbitrary freedom 
in a programming language just for the sake of it" is a couple fewer 
keystrokes and an extremely minuscule reduction in alleged "noise" (the 
usefulness of which is easily canceled out by the fact that reduction in 
inconsistency improves readability too).