On 1/22/11 5:41 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
On 1/22/11 5:14 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu"<seewebsiteforem...@erdani.org> wrote in message
news:ihfm34$jvb$1...@digitalmars.com...
On 1/22/11 4:16 PM, bearophile wrote:
Andrei:
Back then people said that STL's find() is better than D's find()
because the former returns
an iterator that can be combined with either the first iterator to get
the portion before the match, or with the last iterator to get the
portion starting at the match. D's find() only gives you the portion
after the match.
There's a HUGE problem here. This equivalence is sometimes true, but
surely not always true:
"more powerful" != "better"
That function allows you to pick a determined number of elements from a
range, assuming the range is never shorter than that. That sounds a bit
obscure, but plays a pivotal role in findParts() (which is the name I
settled on for the equivalent of Python's partition()):
"trisect" is way better than "findParts" :-) And it's a single word with
no uppercase letters in the middle.
There is still time until the next release. Votes for trisect?
vote--
"findParts" is the sort of thing that once you read what it does just
*once*, it immediately becomes both obvious and easy to remember. But
"trisect" is 1. scary, 2. I'd never remember it, and 3. Whenever I'd come
across it, I'd never remember what it meant. Those are paricularly bad
since I know right now I'm going to find it an incredibly useful function:
There's already been too many times I've written this mess and felt dirty
about it:
auto result = find(str, delim);
auto firstPart = str[0..$-result.length];
So I'm thrilled to see this function being added.
Yes, I'm absolutely in agreement with the naming (and thrilled too). I
imagine a putative user looking through std.algorithm ("let's see...
what find functions are out there?"). That makes findPieces easy to get
to, whereas "trisect" would be oddly situated in the alphabetic list and
oddly named enough to be virtually undiscoverable.
Me a tad less, but not because of the name. I'd still rather see a lazy range
of pre-hit-post tuples. Am I the only one to see findParts as a no-patterns
variation of RegexMatch accepting all element types, not just char? Then even
the name comes naturally -- match.
Lazy in this case is not very helpful because you don't have the
lengths. Turns out it's important to have the length. If not, you can
always use until().
Andrei
