41–46 of 46 posts
Looking at the headings in that TOC, “Preserves“ is a bit of an unfortunate naming choice grammatically.
Yeah I struggle with "Preserve" vs "Preserves" sometimes. Was there something in particular that struck you as unfortunate, though?
Earlier quoted context omitted.
Yeah I struggle with "Preserve" vs "Preserves" sometimes. Was there something in particular that struck you as unfortunate, though?
"Preserves ", for example "Preserves data", reads like "it preserves data". Probably less so in the middle of a sentence, due to the uppercasing, but in the TOC it reads like bullet points enumerating what is preserved.
> This is a good time to mention that even though from a semantic perspective sets and dictionaries do not carry information about the ordering of their elements. Except they do in Python. It is extremely useful, surprisingly often.
Earlier quoted context omitted.
"Preserves ", for example "Preserves data", reads like "it preserves data". Probably less so in the middle of a sentence, due to the uppercasing, but in the TOC it reads like bullet points enumerating what is preserved.
Thank you! I wonder if something a bit contrived such as small-caps could help. I'll experiment.
The name nevertheless feels awkward to me, also in spoken conversation. A made-up word like maybe “Pres” or “Edal” (from “expressive data language”) would work better IMO.
Earlier quoted context omitted.
Protobufs are designed to support schema evolution without explicit versioning. (All fields are optional so they can be added or dropped, provided field numbers aren’t reused.) It looks like Preserves just uses version numbers in its schemas. On the other hand, you can read the data without a schema, similar to JSON.
The version number is the schema language version, not the version of the collection of types described in the file. The schema language is extensible/evolvable in that pattern matching ignores extra entries in a sequence and extra key/value pairs in a dictionary. So you could have a "version 1" of a schema with Person = . and a "version 2" with Person = @v2 / @v1 . Then, Person.v2 from "version 2" would be parseable…
Protobufs have an extra level of indirection built in: code refers to fields using names, but numbers are sent on the wire. Without convenient access to field numbers, they can’t as easily be hard-coded. This also strongly encourages using the schema file for most tasks. With protobufs (or similar), any user-friendly editor will need a schema to make sense of the data.
JSON-like systems and protobufs have opposite design goals: encouraging versus discouraging schemaless data access.
Earlier quoted context omitted.
The version number is the schema language version, not the version of the collection of types described in the file. The schema language is extensible/evolvable in that pattern matching ignores extra entries in a sequence and extra key/value pairs in a dictionary. So you could have a "version 1" of a schema with Person = . and a "version 2" with Person = @v2 / @v1 . Then, Person.v2 from "version 2" would be parseable…
Thanks for the clarification! That sounds about as evolvable as JSON or any system that uses string keys (like HTTP headers). Protobufs have an extra level of indirection built in: code refers to fields using names, but numbers are sent on the wire. Without convenient access to field numbers, they can’t as easily be hard-coded. This also strongly encourages using the schema file for most tasks. With protobufs (or sim…
Person =
Person =
Person = {
@name 1: String
@address 2: Address
}
export type Person = {
name: String,
address: Address,
};