On Fri, 29 Jan 2010 12:42:57 -0500, Pelle Månsson
<[email protected]> 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
