Feature Request: UTF8 version of StringLength function

Question

I just spent a significant amount of time debugging a script where the problem turned out to be that StringLength() was returning the length of "Kö" as 3, because the "ö" is a 2-byte character.

I know there is a PGC_UTF8SubStr() function. Can we also have a PGC_UTF8StringLength() function that is wise to multi-byte characters?

Thanks

Answer 1

I can be done in lua I have used the code at http://www.math.ntnu.no/~stacey/documents/Codea/Library/utf8.lua

You have to change the name of som function when pgc use non standard name in the sandbox.

The function i have not found i a utf8 pattern or regexp in lua. It is har to filter non alphabetic characters

Comments

the modified code exit in my checker at
http://project-gc.com/Tools/Challenges?edit&scriptId=206

---

Thanks for the info.  I will try to make use of this.

Answer 2

As Target. says, it can be solved in LUA. I intend to remove the PGC_UTF8* functions from the documentation since they are not actually needed.

Comments

It is good to know that it can be solved in LUA, but it's rather cumbersome to have to include my own function every time I want to use this functionality.  It would still be much nicer (and make for cleaner code) if there was a function provided.

Similarly, I wouldn't recommend removing the other PGC_UTF8* functions for the same reason.  It means every developer will need to maintain a small library of functions that they paste into every script just to be able to do proper string processing.

---

Project-GC will only provide methods actually needed. As I see it, it's either implementing all checkers and all functions our selves, or providing bare minimum. We have chosen to not implement them all, since it would be almost impossible to both do and maintain, and instead provide the API. The API is intended to provide the data, not process it.

Finding a sweet spot in between would end up with making decisions for this way to often, and the answers would never be fair. Also mixing  PHP and LUA functions makes no sense when it actually works native and it will only add an extra work load, execution time, and risk of incompatibility issues. Also it would then be closed source.

The solution to your issue is rather a PGC-LUA-library that can be included to get those function that commonly are needed. But I have not yet heard anyone presenting an idea that actually is practical and doesn't require weeks of implementation, and I do not think it exists either.

Issues we see, someone has to maintain it. When something needs patching, how should that be done when everything depends on it. Who is responsible, what coding conventions, how to test that it didn't break one of the 5000 scripts which used the function. How to solve that many wants to edit it at the same time. It would all in all end up in being a fairly big project.

PS! I never said I intended to remove the existing functions, only the documentation. The documentation seem to confuse developers into that they are needed, which we thought from the start.