Function calls

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Bill Baxter wrote:
>>> On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at 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