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. -- Tomek