Function calls

Nick Sabalausky a at a.a
Thu Jan 28 16:56:49 PST 2010


"Bill Baxter" <wbaxter at gmail.com> wrote in message 
news:mailman.47.1264724411.4461.digitalmars-d at puremagic.com...
>On Thu, Jan 28, 2010 at 3:58 PM, Nick Sabalausky <a at a.a> wrote:
>> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
>> news:hjt449$5d8$1 at 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();





More information about the Digitalmars-d mailing list