Function calls

[Steven Schveighoffer]

On Fri, 29 Jan 2010 06:16:15 -0500, Pelle Månsson  
<pelle.mansson at gmail.com> wrote:

> On 01/29/2010 05:20 AM, Steven Schveighoffer wrote:
>> Look at it this way (although this is not the only way to look at it),  
>> could byLine be a field inside stdin?  It could.  You could store a  
>> copy of what byLine returns inside stdin, and people could just access  
>> it.
>
> byLine modifies stdin. If you do this:
>
> auto a = stdin.byLine;
>
> You consume a line off stdin.

That's a deficiency in the design of byLine.  It's a range that "primes"  
itself with a line of text.  The fact that you can enter the line above  
and just throw away the data seems error prone to me.  When would you ever  
use that "feature"? In practice, it doesn't matter, because the only  
purpose to fetch the byLine struct is to iterate data from stdin.

The design could be fixed with a boolean isPrimed that is unset on the  
first call to front.  But like I said, it doesn't matter in the long run,  
since nobody ever fetches byLine without using it.

I find that the shoehorning of an input range onto a stream is always  
going to have this problem, so there's not much we can do about it.  It  
doesn't change the concept that byLine is a property.  I find streams much  
better suited to opApply, but I've already had that unsuccessful battle,  
and I don't want to have it again.

>
>> There are some cases that are judgement calls and some that are  
>> obvious.  byLine is obvious.
>
> Apparently not.

I don't see why you think it's not a property.  It fetches a range from  
stdin, there is no other purpose.  If you think byLine's purpose is to  
throw away a line of text, I think first that you are now attaching  
unintended semantic meaning to it (exactly what properties are meant to  
prevent) and second, I'd consider it to be a poorly named function.  I  
guess someone should complain that it's not called popLine(), because as a  
function, that's what it does.

>> The difference is that the *author* is making the judgement call, not  
>> the *user*.  The difference is important, because when a user complains  
>> that your property is doing things a property shouldn't, and then you  
>> realize the "property" in question isn't even a property at all, your  
>> only solution (with the non-attributed system) is to tell the user not  
>> to use it that way.  There is no way to get him to stop, or to get  
>> other users to stop.  You have lost control over the semantic meaning  
>> of your function, even though you defined it and documented it.
>>
>> And yes, this did actually happen to me.
>
> Sounds like a naming issue to me. :)

You be the judge: http://www.dsource.org/projects/tango/ticket/1184

I find the resulting workaround very unsavory.

-Steve