3 ms·

This could be much more terse: {patchset = [ ["+", "/hello", ["world"]], ["!", "/baz", "boo"], ["-", "/foo"] ]} These are basically reified function calls

This could be much more terse: {patchset = [ ["+", "/hello", ["world"]], ["!", "/baz", "boo"], ["-", "/foo"] ]} These are basically reified function calls with known arity, this solution is less XMLish and more lispy, and can be efficiently applied with a bit of destructuring and dispatch on [0].

Spivak 5y ago
This is way less readable to me, you lose all the clarity because now you just have to know all the arguments and order matters.
- electroly 5y ago
  Hmm, is readability the most important thing here? It seems like terseness may be indicated if this is for PATCH requests. Request bodies are almost never compressed. If the patch is too big, you'd be better off just sending the whole file rather than preparing a patch. The unix diff tool's output is very terse and it's a reliable workhorse.
  - shadowgovt 5y ago
    In the 21st century, I rarely hear people suggest we substitute something for the UNIX format. Diff is great as a middle tool but is not nearly as self-descriptive as modern protocols try to be.
    - electroly 5y ago
      When git had the chance to create its own diff format in 2005, it copied the unix diff format. I don't think it's a given that just because it's old, all of its design decisions are wrong. The lack of compression for PATCH request bodies and the need to be smaller than the original file seems, to me, to indicate terseness.
      - shadowgovt 5y ago
        I wasn't implying diff's design decisions were wrong, just that when we greenfield things these days, self-description is a feature where it decidedly wasn't in software built during the era where characters cost money (in ink and paper) to represent. Git was wise to copy diff for backwards compatibility with existing CLI tools because it is primarily accessed via command line. No such backwards-compatibility gain exists with a PATCH protocol over HTTP. In terms of terseness: when servers care about terseness these days, they use a non-ASCII-on-the-wire transport like GRPC. I believe that is out of scope for this RFC.
        electroly 5y ago
        I think (without any kind of supporting evidence) that git chose to use terse diffs so they could be emailed to mailing lists. Git's diffs aren't backwards compatible with patch by default; I'm not sure that was the reason. All of that is to say: I think there are reasons why a modern patch format might reasonably choose terseness. (Personally, I would just push for request body compression. It's not common but it's not impossible, and then you get the best of both worlds. I bet the terse format compresses to roughly the same size as the verbose format.)
- samatman 5y ago
  It's VSO, there is always an operator (six of them), the subject [1] is always a path, and the only one missing an object is remove, which of course has none. Here: const [op, from, to] = patch Now you can read it again. If you want to hashmap from {+, -, !, |, >, ?} to words, that's understandable. Edit: We could simplify this to five verbs by letting + take one or two arguments, where the 1adic form sets the value to null. I mean I wouldn't, but we could.
deleted 5y ago
[deleted]

Spivak 5y ago

This is way less readable to me, you lose all the clarity because now you just have to know all the arguments and order matters.

electroly 5y ago
Hmm, is readability the most important thing here? It seems like terseness may be indicated if this is for PATCH requests. Request bodies are almost never compressed. If the patch is too big, you'd be better off just sending the whole file rather than preparing a patch. The unix diff tool's output is very terse and it's a reliable workhorse.
- shadowgovt 5y ago
  In the 21st century, I rarely hear people suggest we substitute something for the UNIX format. Diff is great as a middle tool but is not nearly as self-descriptive as modern protocols try to be.
  - electroly 5y ago
    When git had the chance to create its own diff format in 2005, it copied the unix diff format. I don't think it's a given that just because it's old, all of its design decisions are wrong. The lack of compression for PATCH request bodies and the need to be smaller than the original file seems, to me, to indicate terseness.
    - shadowgovt 5y ago
      I wasn't implying diff's design decisions were wrong, just that when we greenfield things these days, self-description is a feature where it decidedly wasn't in software built during the era where characters cost money (in ink and paper) to represent. Git was wise to copy diff for backwards compatibility with existing CLI tools because it is primarily accessed via command line. No such backwards-compatibility gain exists with a PATCH protocol over HTTP. In terms of terseness: when servers care about terseness these days, they use a non-ASCII-on-the-wire transport like GRPC. I believe that is out of scope for this RFC.
      - electroly 5y ago
        I think (without any kind of supporting evidence) that git chose to use terse diffs so they could be emailed to mailing lists. Git's diffs aren't backwards compatible with patch by default; I'm not sure that was the reason. All of that is to say: I think there are reasons why a modern patch format might reasonably choose terseness. (Personally, I would just push for request body compression. It's not common but it's not impossible, and then you get the best of both worlds. I bet the terse format compresses to roughly the same size as the verbose format.)
samatman 5y ago
It's VSO, there is always an operator (six of them), the subject [1] is always a path, and the only one missing an object is remove, which of course has none. Here: const [op, from, to] = patch Now you can read it again. If you want to hashmap from {+, -, !, |, >, ?} to words, that's understandable. Edit: We could simplify this to five verbs by letting + take one or two arguments, where the 1adic form sets the value to null. I mean I wouldn't, but we could.

deleted 5y ago

[deleted]