Function calls

Nick Sabalausky a at a.a
Thu Jan 28 19:47:35 PST 2010


"Nick Sabalausky" <a at a.a> wrote in message 
news:hjtl33$1dag$1 at digitalmars.com...
> "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).
>

We can keep dancing around it with different evidence, metaphors and 
philosophies all we want, but the bottom line is, omittable parens are a 
feature, and they just happen to be a feature that 1. causes problems and 2. 
provides extremely minimal benefits. And what do we do with features that 
cause problems and provide extremely minimal benefits? We yank 'em.





More information about the Digitalmars-d mailing list