3 ms·

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 `S

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.

llogiq 11y ago
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'.
- Pxtl 11y ago
  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.
- jdmichal 11y ago
  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.
  - lomnakkus 11y ago
    > 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.
    - Gankro 11y ago
      And on Windows it's "potentially ill-formed UTF-16": https://simonsapin.github.io/wtf-8/ 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?
      - gsnedders 11y ago
        > 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).
Pxtl 11y ago
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.
deleted 11y ago
[deleted]

llogiq 11y ago

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'.

Pxtl 11y ago
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.
jdmichal 11y ago
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.
- lomnakkus 11y ago
  > 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.
  - Gankro 11y ago
    And on Windows it's "potentially ill-formed UTF-16": https://simonsapin.github.io/wtf-8/ 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?
    - gsnedders 11y ago
      > 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).

Pxtl 11y ago

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.

deleted 11y ago

[deleted]