Consider using JSON Schema and QuickType instead of custom schema

[simoncozens]

I started writing TypeScript .d.ts declarations for Fontra classes, to help with development and create a more declarative interface, and found I was duplicating information already present in the classes.json file. When trying to turn this classes.json into declarations programmatically, I stumbled across QuickType. QuickType is a Javascript library which transforms type information (in JSON, JSON Schema or Postman format) into class definitions, including serializers and deserializers, for multiple languages; it can emit JavaScript, TypeScript, Python data classes, etc.

This creates two possibilities:

• The less disruptive approach: If the existing fontra.core.classes module were to emit a JSON Schema file like so:

{
  "$schema": "http://json-schema.org/draft-07/schema",
  "definitions": {
    "FontInfo": {
      "type": "object",
      "properties": {
        "familyName": {
          "type": "string",
          "optional": true
        },
// ...
  "type": "object",
  "properties": {
    "unitsPerEm": {
      "type": "integer"
    },
    "fontInfo": {
      "$ref": "#/definitions/FontInfo"
    }
  }
}

then instead of classes.js, we could generate the relevant Javascript classes automatically with QuickType. The fromObject definitions would also go away, as the QuickType code would include a deserializer.

• The more disruptive approach: If the JSON Schema document was hand-written, then both the Javascript and the Python class definitions could be generated automatically by QuickType.

I'm happy to work on either of these if thought to be a good idea.

[justvanrossum]

I prefer the Python classes to be the source for everything.

Would QuickType only be a build-time dependency?

[simoncozens]

Yes, similar to the way -m fontra.core.classes works right now: write out the Javascript classes during build time.