On 1/13/14 4:53 AM, Regan Heath wrote:
On Fri, 10 Jan 2014 16:30:12 -0000, Andrei Alexandrescu
<[email protected]> wrote:
The way I see it one learns a name for an algorithm (low cognitive
load) and then uses it everywhere. This is not Go.
Sure. But, lets take an example: std.algorithm.canFind is more or less
what you might call std.string.contains (which does not exist - instead
we'd use indexOf != -1.. I think).
Well there's no perfection in this world :o).
What is the harm in having an alias in std.string called contains which
simply calls std.algorithm.canFind?
I think you can answer that for yourself. Just take the approach to its
logical conclusion.
Sure, it opens the door to someone using both canFind and contains on
strings in their code. So what? Use of contains is more
likely/intuitive for string related code, but both are intelligible.
canFind will be more likely in generic code, where you would think of
that generic algorithm name.
It seems to me that people think of algorithms by different names in
different contexts. In the context of strings "contains" would make the
most intuitive sense to the most people.
I agree that good names are difficult to find. I think you'd have a hard
time with a "the more the merrier" stance.
Side-issue.. from std.algorithm:
bool canFind(alias pred = "a == b", R, E)(R haystack, E needle) if
(is(typeof(find!pred(haystack, needle))));
Returns true if and only if **value** can be found in range. Performs
Ο(needle.length) evaluations of pred.
What is **value** shouldn't that be needle?
Please file a bug or pull request. Thanks!
Andrei
