Function calls

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Jan 28 17:07:53 PST 2010


Nick Sabalausky wrote:
> "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();

Because a function doesn't attempt to emulate a field.

Andrei



More information about the Digitalmars-d mailing list