Function calls

[Bill Baxter]

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.

--bb