4 ms·
>With UTF-8 you would give up some constant time operations like character lookups if Java had a non-broken string API, even with the current UCS-2 based solut
by pilif 11y ago
>With UTF-8 you would give up some constant time operations like character lookups
if Java had a non-broken string API, even with the current UCS-2 based solution they couldn't do constant-time character lookups.
And even if Java went the extra mile of using characters big enough to encode every code point of a string, constant lookup would still not be possible because users are often interested graphemes, not characters.
- MrBuddyCasino 11y agoThat is sadly true, but at least for the Basic Multilingual Plane, charAt() and codePointAt() return correct results in constant time. The only non-broken methods are afaik codePointCount() and offsetByCodePoint(), which, as you pointed out, are not that interesting anyway. Do you know of an example of a well-designed String API? I'd be interested in what trade-offs other language designers made (newer ones, like Rust/Swift/Go/?).
- ygra 11y agoIMHO Python gets strings very right. The internal representation is variable, depending on the string's content (to save memory), and the external API only gives you access to code points.
- gsnedders 11y agoThat's only Python 3.3 and above; before that it was an under-defined mess, in CPython depending on compile-time options and often broken with the same UCS-2/UTF-16 mess as numerous other languages.
- TheLoneWolfling 11y agoThe problem with Python strings is that innocuous operations can occasionally cause drastic memory usage ballooning. A simple string append can, for instance, require up to 5x the memory consumed by the string. Worse, this problem will only show up if someone ever enters in a high enough code point. Better hope any user-defined data never gets turned into part of a large string at any point, or you have a potential memory problem down the line.