3 ms·

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

by 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).

by llogiq 11y ago

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