Hacker News Reader

Comment by jdmichal | Hacker News Reader

To be fair, Java and C# -- two languages that you would probably consider as having one unicode string type -- also effectively have two string types between `String` and `StringBuilder`. [0] Java also has `java.nio.file.Path`. [1]

[0] Java also manages to conflate synchronization into the mix with `StringBuffer`.

[1] C# (thankfully) just has static functions to manipulate strings as paths.

View on HN

If you want to add IO into Java's mix, you can also use StringWriter.

Also I personally don't consider paths as strings, nor URLs – both are types for specific purposes with specific invariants, which are distinct from strings'.

Agreed, as long as the language provides quick and fast go/from string mechanism, great them as their own objects. What drives me batty is when I know something is just a string under the hood but getting my string into that object is a nightmare and inconsistent.

I suppose it depends on your definition of a string. If it's an ordered collection of glyphs, than paths and URLs are definitely strings with invariant restrictions. But, of course, that's hardly a useful definition when you need to take a URL as input, is it? So I agree that treating them as separate types with an external string representation is a very useful tool to have, even if I don't agree that it should always be applied! Having worked with the Path class in Java, I personally find it an impediment to understandable code, but I'd also be willing to accept that that particular implementation and my intuition simply don't mesh well.

> I suppose it depends on your definition of a string. If it's an ordered collection of glyphs, than paths and URLs are definitely strings with invariant restrictions.

That's not quite true -- on POSIX paths are strings of bytes. POSIX doesn't specify any particular encoding[1]. AFAIR the only restrictions on paths are around the NUL (0) byte and '/' (47).

[1] I'm sure we'd all be happier if Unicode (encoded as UTF-8) were specified as the way to do paths, but POSIX was invented quite a bit before Unicode & UTF-8, so here we are.

And on Windows it's "potentially ill-formed UTF-16": https://simonsapin.github.io/wtf-8/

Basically if your language/std-lib claims to be cross platform and considers paths to be definitely-utf8, it's busted. I think, maybe, plan9 is a case where this claim holds?

> And on Windows it's "potentially ill-formed UTF-16"

On Windows, and in many Windows APIs, the return value is a "sequence of UTF-16 code units" (which is essentially a fancy way of saying "a sequence of 16-bit words"). This goes back to Windows originally using UCS-2, where any sequence of 16-bit words is valid (because there wasn't any concept of a surrogate, yet alone a lone surrogate), given its support predates the Unicode consortium extending Unicode to 21-bits and along with it UTF-16's existence (1996).

Honestly, having coded a lot of C# path code, I'd rather an object that properly encapsulates this, as long as there's easy APIs to get a string copy from it and vice versa - I mean, you're going to be throwing away oodles of string refs anyways since they're immutable, so one more for the path conversion wouldn't hurt and the path API would be a lot cleaner.

Reply on news.ycombinator.com