Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Michiel Helvensteijn wrote:
Bill Baxter wrote:
byLine() is a function. It changes the state of stdin. Calling it
consecutively will in general result in different return values. If
there
were two guys: stdin.currentLine (property) and stdin.nextLine(), it
would be a different story.
That's not how it works, I think.
Just calling byLine() by itself only returns a range struct.
Consuming things from that range is what changes the state of stdin.
Ah, my bad. I was guessing. Still, returning a handle from a property
that
can change the state of the originating object is.. iffy.
I agree. So where's the consensus? Things seemed so clear when people
were
beaten with @property over their head.
I really don't see what the problem is there.
You are arguing that car.wheels should not be a property simply
because it would let me change the color of the wheels (which are part
of the car's total state)?
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.
Andrei
