"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:hjtet5$111...@digitalmars.com... > Nick Sabalausky wrote: >> "Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message >> news:hjtcbd$r0...@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).
