Nick Sabalausky wrote:
"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();
Because a function doesn't attempt to emulate a field.
Andrei
