"Bill Baxter" <wbax...@gmail.com> wrote in message news:mailman.47.1264724411.4461.digitalmar...@puremagic.com... >On Thu, Jan 28, 2010 at 3:58 PM, Nick Sabalausky <a...@a.a> wrote: >> "Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message >> news:hjt449$5d...@digitalmars.com... >>> Bill Baxter wrote: >>>> On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu >>>>> >>>>> The problem is not localized change. The result of stdin.byLine >>>>> changes >>>>> the >>>>> _entire_ stdin. >>>> >>>> Ok, so you have no problem with a car.wheels returning a mutable wheels >>>> object? >>>> So it's only when the returned property can change the entire state >>>> (or a lot of the state?) that you have a problem? >>>> I don't understand how degree changes the acceptability. Doesn't seem >>>> like it should matter to me. >>> >>> If you access car.wheel, it is reasonable to repaint that wheel. The >>> problem is that you can use car.wheel to repaint the car. >>> >> >> Ok, so you don't think a property of something should be able to change >> other parts of that something? Ok, I can understand that. But if that's >> so, >> then how would it be any better to be able to change something through >> the >> return value of one of that something's member functions? (Which, of >> course, >> is what stdin.byLine apperently already does.) >> >> Ie, Given this code: >> >> auto foo = stdin.byLine; >> foo.doSomethingThatAdvancesStdin(); >> >> How is it possible for that code to be bad when "byLine" is defined as a >> "@property", but suddenly be perfectly fine when omittable parens are >> allowed and it's defined without "@property", even though either way it's >> still the exact same code doing exactly the same thing and having exactly >> the same effects? > >That's not a contradiction in Andrei's position at all. Because if >there is no @property, then all that dropping parens means is that >it's a no-function argument.
I assume you meant "no-argument function". 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();
