s🔡 🔍❗ now returns grapheme index instead of UTF-8 index

[joeskeen]

s🔡 🔍❗ now returns grapheme index instead of UTF-8 index

Fixes #208

[thbwd]

Thanks for immediately opening a PR to fix this! Unfortunately, your implementation runs in O(n) in terms of memory as 🔪 allocates memory for each substring. Do you think you could maybe create an overload of 🎼 that takes a start index from which to compare? Then no substring would be needed.

[joeskeen]

OK I'll look into using that approach. Thanks for the feedback!

[joeskeen]

@thbwd I've started the approach you suggested, but it looks like I'm running into the same problem that caused the issue to begin with. Once I get over to the C++ side, the sStringBeginsWith code uses a memory comparison between string->characters.get(), beginning->characters.get(). There isn't enough context here to be able to determine where in the string to start comparing since we would have to get the graphemes, measure them, and then start the memory comparison at that calculated index. And since this would still be done in a loop, this code would have to be called multiple times.

I'm wondering if there would be a better approach involving passing not only the source string, but also the source string in grapheme array form, allowing that operation to only be done once.

[joeskeen]

OK @thbwd I believe this is ready to be reviewed again.

[thbwd]

While I think this should work, we could improve this even further by exposing an iterator that works like sStringCodepoints as an API in Emojicode. This would get rid of the array allocation. Let me know what you think 🙂

[thbwd]

I think it should be runtime::Integer instead of int here. https://www.emojicode.org/docs/guides/api.html#function-signatures

[thbwd]

Also, I think it would be better to check [string->characters.get() + utf8Index, string->characters.get() + utf8Index + beginning->count) is in bounds here, as this method is exposed publicly below.

[thbwd]

This can be moved after the if statement