Should this work?
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Wed Jan 22 11:39:14 PST 2014
On 1/13/14 4:53 AM, Regan Heath wrote:
> On Fri, 10 Jan 2014 16:30:12 -0000, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> 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
More information about the Digitalmars-d
mailing list