Function calls
Nick Sabalausky
a at a.a
Thu Jan 28 19:36:03 PST 2010
"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).
More information about the Digitalmars-d
mailing list