Function calls

[Steven Schveighoffer]

On Fri, 29 Jan 2010 12:42:57 -0500, Pelle Månsson  
<pelle.mansson at gmail.com> wrote:

> On 01/29/2010 02:01 PM, Steven Schveighoffer wrote:
>> 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.
>
> So byLine should be a property when implemented as a range, and a  
> function when implemented as an opApply based loop?

I meant byLine should return a struct that implements opApply.  If it is a  
function then you have to pass the address to foreach, which is a little  
awkward.

>> You be the judge: http://www.dsource.org/projects/tango/ticket/1184
>>
>> I find the resulting workaround very unsavory.
>>
>> -Steve
>
> That's the assignment syntax, which I do agree is weird. Sorry if I was  
> unclear. This is what I thought @property was for.
>
> It has, however, nothing to do with the omitting of the ().

No, but it is an example of someone misinterpreting the meaning of a  
function because the compiler accepted his syntax.  Yes, the assignment  
rewrite is more troublesome than the getter, but being able to force  
someone to omit the parentheses has its advantages:

user1: When I call range.empty(), it doesn't clear the range
developer:  Hm.. empty is not an action, its a property.  Maybe I'll fix  
it by changing it to isEmpty to make it clear.
user1: great idea! that's much clearer.

....

user2: Why did you name it isEmpty, isn't the 'is' redundant since this  
looks perfectly normal? if(r.empty)
developer: *sigh*

This is the problem I ran into.  Because so much meaning is attached to  
the () by humans, you must resort to naming conventions to make the  
intentions clear, then point out the reasons for not using a better name  
to future complainers.  Note in the anecdote above, both users would have  
been satisfied if you could *only* call empty without parentheses.

The no-parens property requirement has nothing to do with compiler  
interpretation or functionality and everything to do with human  
interpretation.  It's all about what does the call *look* like it's doing  
as opposed to what it actually does.  By enforcing the removal of  
parentheses, most normal users don't have to read the docs or look at  
anything else.  It just works the way it's supposed to work, and looks  
like it does that.  This doesn't make every single case clear, nor does it  
install automatic wisdom in all developers to be able to invent intuitive  
names.  What it does is make it *possible* for you to invent intuitive  
names that retain their meaning and are succinct.  I don't know about you,  
but using libraries with intuitive, consistent, and succinct terminology  
is really much more enjoyable than ones with inconsistent or overly  
verbose terminology.

The other benefit is it makes calling delegate properties less ugly and  
more consistent with analogous fields.

-Steve