On 24 January 2014 21:49, Regan Heath <regan@netmail.co.nz> wrote:

> On Fri, 24 Jan 2014 08:21:12 -0000, Jacob Carlborg <doob@me.com> wrote:
>
>> I would expect "contains" to take a element and check if it exists in the range.
>>
>
> Except in the case of string, where we also want an overload taking more than a single element aka a substring.


A great example of when the string function should not be conflated with the general function.

On Saturday, 25 January 2014 at 09:18:24 UTC, Manu wrote:
> On 24 January 2014 21:49, Regan Heath <regan@netmail.co.nz> wrote:
>
>> On Fri, 24 Jan 2014 08:21:12 -0000, Jacob Carlborg <doob@me.com> wrote:
>>
>>> I would expect "contains" to take a element and check if it exists in the
>>> range.
>>>
>>
>> Except in the case of string, where we also want an overload taking more
>> than a single element aka a substring.
>
>
> A great example of when the string function should not be conflated with
> the general function.

You always want the overload.

If this works:

    contains("hello", "el");

then this should work:

    contains([1, 2, 3, 4, 5], [2, 3]);

Special cases are pure evil. There's nothing special about strings in this case.

On Saturday, 25 January 2014 at 10:15:30 UTC, Peter Alexander wrote:

> You always want the overload.
>
> If this works:
>
>     contains("hello", "el");
>
> then this should work:
>
>     contains([1, 2, 3, 4, 5], [2, 3]);
>
> Special cases are pure evil. There's nothing special about strings in this case.

I agree. Since strings are just a kind of array, it would be stupid to not allow the above.

--
/Jacob Carlborg

On Saturday, 25 January 2014 at 10:15:30 UTC, Peter Alexander wrote:
> If this works:
>
>     contains("hello", "el");
>
> then this should work:
>
>     contains([1, 2, 3, 4, 5], [2, 3]);
>
> Special cases are pure evil. There's nothing special about strings in this case.

I don't disagree, but naming and intuitive semantics should match up. In this case it does not. "contains" signifies  set membership.

hasSequence/findSequence would be more appropriate

On Saturday, 25 January 2014 at 11:43:03 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 25 January 2014 at 10:15:30 UTC, Peter Alexander wrote:
>> If this works:
>>
>>    contains("hello", "el");
>>
>> then this should work:
>>
>>    contains([1, 2, 3, 4, 5], [2, 3]);
>>
>> Special cases are pure evil. There's nothing special about strings in this case.
>
> I don't disagree, but naming and intuitive semantics should match up. In this case it does not. "contains" signifies  set membership.
>
> hasSequence/findSequence would be more appropriate

100% agree. The key thing is that it should be consistent between strings and other range types.

On Saturday, 25 January 2014 at 14:23:48 UTC, Peter Alexander wrote:
> 100% agree. The key thing is that it should be consistent between strings and other range types.

Indeed. It is better to have to look up the name in the beginning.

Also, a good IDE will give you a list of alternatives and it is important to keep this list as short as possible. Ideally there should be no more than 10 functions for any type in order to maximize the benefit of using an IDE. So few functions, but with very descriptive names make me more efficient (I don't have to look it up in the documentation).

Basically, it is better to have a small core that can be used with lambdas for the specifics. I notice when I do Python that I don't use all the special functions. I use the generic ones with lambdas instead.

On Saturday, 25 January 2014 at 09:18:24 UTC, Manu wrote:
> On 24 January 2014 21:49, Regan Heath <regan@netmail.co.nz> wrote:
>
>> On Fri, 24 Jan 2014 08:21:12 -0000, Jacob Carlborg <doob@me.com> wrote:
>>
>>> I would expect "contains" to take a element and check if it exists in the
>>> range.
>>>
>>
>> Except in the case of string, where we also want an overload taking more
>> than a single element aka a substring.
>
>
> A great example of when the string function should not be conflated with
> the general function.

Both `find` and `canFind` support subrange search, and that works with any range, not just substrings.

On 25 January 2014 20:15, Peter Alexander <peter.alexander.au@gmail.com>wrote:

> On Saturday, 25 January 2014 at 09:18:24 UTC, Manu wrote:
>
>> On 24 January 2014 21:49, Regan Heath <regan@netmail.co.nz> wrote:
>>
>>  On Fri, 24 Jan 2014 08:21:12 -0000, Jacob Carlborg <doob@me.com> wrote:
>>>
>>>  I would expect "contains" to take a element and check if it exists in
>>>> the
>>>> range.
>>>>
>>>>
>>> Except in the case of string, where we also want an overload taking more than a single element aka a substring.
>>>
>>
>>
>> A great example of when the string function should not be conflated with the general function.
>>
>
> You always want the overload.
>
> If this works:
>
>     contains("hello", "el");
>
> then this should work:
>
>     contains([1, 2, 3, 4, 5], [2, 3]);
>
> Special cases are pure evil. There's nothing special about strings in this case.
>

Does that work in all cases of strings wrt utf encodings? String
normalisation? What about when char and wchar strings are compared? (should
that should be handled transparently?)
Strings are special, they're almost always special, and rarely conflate
with generalisations well.
Strings almost always exposes special cases that aren't useful or relevant
for any other context.

On 1/25/14 6:07 PM, Manu wrote:
> On 25 January 2014 20:15, Peter Alexander <peter.alexander.au@gmail.com
> <mailto:peter.alexander.au@gmail.com>> wrote:
>     If this works:
>
>          contains("hello", "el");
>
>     then this should work:
>
>          contains([1, 2, 3, 4, 5], [2, 3]);
>
>     Special cases are pure evil. There's nothing special about strings
>     in this case.
>
>
> Does that work in all cases of strings wrt utf encodings?

Yes.

> String normalisation?

Not automatically, but you could do things such as find(haystack.byGrapheme, needle.byGrapheme).

> What about when char and wchar strings are compared?

Yes.

> (should that should be handled transparently?)

It is. D's stdlib is one of very few languages that can do this out of the box without converting one to the other.

> Strings are special, they're almost always special, and rarely conflate
> with generalisations well.

There is considerable evidence that the above is wrong.

> Strings almost always exposes special cases that aren't useful or
> relevant for any other context.

The special cases I found almost always involve whitespace (there is no obvious generalization of the notion). Other than that, UTF strings are nothing else but boring variable-length encodings.


Andrei

Am Sat, 25 Jan 2014 14:36:52 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang@gmail.com>:

> On Saturday, 25 January 2014 at 14:23:48 UTC, Peter Alexander wrote:
> > 100% agree. The key thing is that it should be consistent between strings and other range types.
> 
> Indeed. It is better to have to look up the name in the beginning.

If the name works well for strings, I agree. But otherwise I prefer established function names from popular languages like Python, Pascal/Delphi or Java.

> Also, a good IDE will give you a list of alternatives and it is important to keep this list as short as possible. Ideally there should be no more than 10 functions for any type in order to maximize the benefit of using an IDE. So few functions, but with very descriptive names make me more efficient (I don't have to look it up in the documentation).

There are 360 completions for a string already in Mono-D with these imports:

import std.algorithm;
import std.array;
import std.conv;
import std.range;
import std.stdio;
import std.string;
import std.traits;

Don't bother with removing two or three function names for string overloads. That's optimizing in the wrong area. :)

-- 
Marco