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. In the original D1 scheme, .foo just means foo is either field or a zero-arg function. Nothing more nothing less. The problem is that you can't tell if the coder meant it to be a property or not, and this bites you in cases like returning callable. --bb
