Allow interpreter override

[artur-ciocanu]

Problem statement

Today modelina allows different customizations via preset mechanism. It works great for most of the cases, however there are situations when customizing the code generator output is impossible, because of some of the hard-coded logic that can be found in processors and interpreter.
For example, if we want to customize the output of the schema field that have additionalProperties, then we really have no choice, but to accept that any field that looks like this:

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "title": "Test",
  "type": "object",
  "properties": {
    "prop": {
      "type": "object",
      "additionalProperties": false
    }
  },
  "additionalProperties": false,
  "required": [
    "id"
  ]
}

Will be translated into something like this (e.g. Java code gen):

public class Test {
  private Prop prop;

  public Prop getProp() { return this.prop; }
  public void setProp(Prop prop) { this.prop = prop; }
}

public class Prop {
  
}

Which is quite unfortunate since we can do anything useful with this Java class. I would argue that the above schema declaration should generate something like this:

public class Test {
  private Object prop;

  @JsonProperty("prop")
  public Object getProp() { return this.prop; }
  public void setProp(Object prop) { this.prop = prop; }
}

I would like to mention that if we use a schema like this:

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "title": "Test",
  "type": "object",
  "properties": {
    "prop": true
  },
  "additionalProperties": false,
  "required": [
    "id"
  ]
}

Or

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "title": "Test",
  "type": "object",
  "properties": {
    "prop": {
       "title": "Prop"
    }
  },
  "additionalProperties": false,
  "required": [
    "id"
  ]
}

Then we get a property of type Object. As far as I can tell all the 3 schema definitions are equivalent from code generation perspective, however since InterpretAdditionalProperties can't be customized we can't do anything about it.

Possible solution

One possible solution is to allow clients to pass custom interpreters for all the different properties like oneOf, anyOf, additionalItems, additionalProperties, etc. This is somewhat similar to the way we can create custom presets and add them via config.

@jonaslagoni let me know your thoughts? Is this something that we could try in next branch?

[jonaslagoni]

I honestly don't see anything wrong with this, great suggestion @artur-ciocanu!

It's backward compatible and a feature we can slowly roll out, so I see no issues with pursuing this 🙂

Do you want to take a crack at it?

[artur-ciocanu]

Hey @jonaslagoni sorry for a late reply. Yeah, I'll try opening a PR.