Sean Kelly wrote:
I'm not terribly fond of the added verbosity however, or that this seems
like I couldn't use the property form:
assumeSorted("abcd").find('c')
Truth be told, my initial inclination would be to repackage the binary
search as a one-liner with a different name, which kind of sabotages the
whole idea. But I'll try to resist this urge.
I understand. This is rather new, but I found it irresistibly cool to
unify find() routines under one name and specify structure in the
arguments' types. Usage is very easy, there's little to remember, and
every piece of structure is where it should be. Consider:
int[] a = [ 1, 2, 3, 4 ];
int[] b = [ 2. 3 ];
These algorithms each performs search a different way because each is
informed in different ways about the structure of their arguments:
find(a, b);
find(assumeSorted(a), b);
find(a, assumeSorted(b));
find(assumeSorted(a), assumeSorted(b));
find(a, boyerMooreFinder(b));
There's three names to remember that compose modularly. The
run-of-the-mill approach is:
find(a, b);
binaryFind(a, b);
findRhsSorted(a, b);
binaryFindRhsSorted(a, b);
boyerMooreFind(a, b);
To add insult to injury, boyerMooreFind is not enough because it hides
the structure created around b. So there's also need for one extra type
e.g. BoyerMooreFinder!(int[]) for cases when there are multiple searches
of the same thing. It's just onerous.
Andrei
P.S. By the way, this is the running example used in Chapter 4 of TDPL.
