3 ms·

>I think the first part of your argument works equally well for strings generally as for typed strings, But NameAscii.CharacterIndex(3) is a different meaning

by jasode 11y ago

>I think the first part of your argument works equally well for strings generally as for typed strings, But NameAscii.CharacterIndex(3) is a different meaning than NameUtf16.CharacterIndex(3). The byte index could be 3 or 6+n depending on semantics. >Sure, but I don't think it has to be done twice. [...]abstracting the URL-iness of strings, There's no redundancy. If I have a config file that has user-specified URLs in it. It is more likely that the programmer will know if that file on disk is ASCII or Utf16. The programmer can know that before the compiler or runtime can know it and assign a formal type to the incoming string. This is independent knowledge from a URL data type. A URL data type isn't going to have member functions to pull data directly off of the disk. That's a separate concern as you say. >, adding something to abstract the URL-iness of a byte sequence is a gratuitous redundancy that conflicts with the principle of separating concerns. We are envisioning different things. I thought of it as: - bytes -> typed string -> URL I think you're thinking of: - -- typed string - bytes / - \-- URL ... and yes that would be redundant for a URL data type to understand all kinds of raw bytes.

deleted 11y ago
[deleted]
mannykannot 11y ago
What I am actually thinking of is this: bytes -> string -> URL -> SQL ... Once you type strings, you get multiplicities. Completing your diagram, we get bytes -> string -> URL-string -> URL -> SQL-string -> SQL ... or bytes -> string -> URL-string -> URL -> SQL-string -> SQL ... There's the redundancy. What are the typed strings doing for us? Edit: I don't think these diagrams are formally correct - I don't think of URL as a subtype of string, even though it has a string representation and URL objects can be constructed from strings - but I think they make my point clear.
- jasode 11y ago
  (LATE EDIT: I now see that your responses were influenced by cballard's original examples of NSURL and NSString but I wasn't talking about those.) I was thinking of ASCII/Unicode string types and not the URLString vs SQLString types. Yes, a URLString would be redundant. In C#, the URI data type contains a Utf16 string as a data member but it is not another type of string. We were talking about different things. The ASCII/Unicode string data types would be somewhat analogous to int32/int64/float32/float64/Money data types. The way C# does it is that everything is Utf16 and there is no separate ASCIIString data type for pure ASCII strings. They also don't have pure Utf8 strings. Instead, the UTF16 classes has member "get()/encode()" functions that interpret as ASCII or UTF8. The ASCII/Utf8 data state is transitory. This architectural choice is fine for most apps but if you have 1 gigabyte of ASCII data, it's very memory inefficient to double the memory footprint to 2 GB for Utf16 just to slice & dice strings. If you use byte[] arrays to keep everything as raw ASCII to conserve memory, you don't get any convenient string-like slice & dice functions. The "string type" is lost in a opaque byte[] array.
  - mannykannot 11y ago
    > We were talking about different things. You started by disagreeing with kazinator's objection to typed strings, and for several posts after that you explicitly defended the concept of typed strings. Now you are trying to rewrite the discussion as if it were about the internal representation of strings, which it has never been.
    - jasode 11y ago
      >You started by disagreeing with kazinator's objection to typed strings, You misunderstood our subthread. Kazinator was talking about "fat" strings. I was pointing out that there can be "string types" that helps detect defects. We had 2 different ideas of "string types". I can't say we disagreed insomuch as clarified what each of us was talking about. I also don't care for your accusatory tone as if I'm deceiving people. My examples of string types has been consistent from the very beginning. I was never talking about NSURL/UrlString but you did. I simply didn't pick up on that divergence which was huge. Also, an internal memory representation has ramifications on external semantics. That's not a rewrite. That's been my point all along (see my earlier clipboard example). A sequence of of bytes on disk, or network port, or memory always requires correct semantics to process.

by jasode 11y ago

deleted 11y ago

[deleted]

mannykannot 11y ago

What I am actually thinking of is this: bytes -> string -> URL -> SQL ... Once you type strings, you get multiplicities. Completing your diagram, we get bytes -> string -> URL-string -> URL -> SQL-string -> SQL ... or bytes -> string -> URL-string -> URL -> SQL-string -> SQL ... There's the redundancy. What are the typed strings doing for us? Edit: I don't think these diagrams are formally correct - I don't think of URL as a subtype of string, even though it has a string representation and URL objects can be constructed from strings - but I think they make my point clear.

jasode 11y ago
(LATE EDIT: I now see that your responses were influenced by cballard's original examples of NSURL and NSString but I wasn't talking about those.) I was thinking of ASCII/Unicode string types and not the URLString vs SQLString types. Yes, a URLString would be redundant. In C#, the URI data type contains a Utf16 string as a data member but it is not another type of string. We were talking about different things. The ASCII/Unicode string data types would be somewhat analogous to int32/int64/float32/float64/Money data types. The way C# does it is that everything is Utf16 and there is no separate ASCIIString data type for pure ASCII strings. They also don't have pure Utf8 strings. Instead, the UTF16 classes has member "get()/encode()" functions that interpret as ASCII or UTF8. The ASCII/Utf8 data state is transitory. This architectural choice is fine for most apps but if you have 1 gigabyte of ASCII data, it's very memory inefficient to double the memory footprint to 2 GB for Utf16 just to slice & dice strings. If you use byte[] arrays to keep everything as raw ASCII to conserve memory, you don't get any convenient string-like slice & dice functions. The "string type" is lost in a opaque byte[] array.
- mannykannot 11y ago
  > We were talking about different things. You started by disagreeing with kazinator's objection to typed strings, and for several posts after that you explicitly defended the concept of typed strings. Now you are trying to rewrite the discussion as if it were about the internal representation of strings, which it has never been.
  - jasode 11y ago
    >You started by disagreeing with kazinator's objection to typed strings, You misunderstood our subthread. Kazinator was talking about "fat" strings. I was pointing out that there can be "string types" that helps detect defects. We had 2 different ideas of "string types". I can't say we disagreed insomuch as clarified what each of us was talking about. I also don't care for your accusatory tone as if I'm deceiving people. My examples of string types has been consistent from the very beginning. I was never talking about NSURL/UrlString but you did. I simply didn't pick up on that divergence which was huge. Also, an internal memory representation has ramifications on external semantics. That's not a rewrite. That's been my point all along (see my earlier clipboard example). A sequence of of bytes on disk, or network port, or memory always requires correct semantics to process.