Compositional creation for allOf types

[idg10]

I have an application that produces various forms out JSON output where there is some overlap between the property set. I'm using a mix-in-like approach, so one type might start like this:

    "transitiveFrameworkReferenceTestRun": {
      "allOf": [
        { "$ref": "./CommonSchema.json#/$defs/testRun" },
        { "$ref": "./CommonSchema.json#/$defs/bloatTestResults" }
      ],
      "properties": {
...

another might

    "extensionMethodsWorkaroundTestRun": {
      "allOf": [
        { "$ref": "./CommonSchema.json#/$defs/testRun" },
        { "$ref": "./CommonSchema.json#/$defs/buildResults" },
        { "$ref": "./CommonSchema.json#/$defs/bloatTestResults" }
      ],
      "properties": {

and another is like this:

    "issue97TestRun": {
      "$ref": "./CommonSchema.json#/$defs/testRun",
      "properties": {

So in this particular app, it happens that all of these ...TestRun types are all instances of testRun. And then there are some other common sets of properties that I want to appear in some but not all of these types.

This works, but the thing I would like to be able to do in C# is build up some of these allOf types from the components. Suppose I already have a TestRun and BloatTestResults in hand, I'd like to be able to supply these directly when building a TransitiveFrameworkReferenceTestRun.

Currently, the TransitiveFrameworkReferenceTestRun.Create method effectively requires me to deconstruct and reassemble the things:

TransitiveFrameworkReferenceTestRun.Create(
  deployedWindowsForms: bloatTestResults.DeployedWindowsForms,
  deployedWpf: bloatTestResults.DeployedWpf,
  testRunDateTime: testRun.TestRunDateTime,
  testRunId: testRun.TestRunId,
  ... properties defined directly by transitiveFrameworkReferenceTestRun
);

It's not a huge issue, and I don't expect we'd gain a performance benefit from being able to assemble it from the larger chunks. Even deconstructing and reconstructing like this will result in a TransitiveFrameworkReferenceTestRun that is effectively pointing to the same data as the inputs. But it would be convenient to be able to just plug the bigger pieces together:

TransitiveFrameworkReferenceTestRun.Create(
  bloatTestResults,
  testRun,
  ... properties defined directly by transitiveFrameworkReferenceTestRun
);

Possibly there is already some way of doing this that I've not discovered.

[mwadams]

You have hit on an interesting composition case, and yes, the way we handle this at the moment is to offer a create method that requires you to deconstruct the pieces and reassemble them, which is a bit of a pain.

Partly this is because I couldn't figure out a straightforward way to avoid repeatedly setting the same values if you have overlaps as you describe, and I decided to make it the caller's problem. However, that is a little unfair as there is no reason you couldn't have both (apart from API bloat).

For vNext there is a slightly different pattern for intialization/creation (as part of supporting mutability), and it seems plausible that I could provide a "create" function which allowed you to pass a set of sources for each of the allOf instances, plus any locally defined properties, for the case where we are trivially a set of allOf instances.

I have done something similar for a degenerate anyOf, oneOf where you can just pass a source for one or other of those types.

[idg10]

Ah, the 'overlap' in my case did not mean that the same property name turns up in multiple sets. The schemas in the allOf in my case all define disjoint sets of properties. The 'overlap' is that when we come to the top-level types (the ones using allOf) they have some properties in common.

I'm expressing that overlap by defining non-overlapping property groups (e.g., testRun, bloatTestResults) that show up in multiple different types' allOfs.

So in this case the "repeatedly setting the same values" problem doesn't arise.

I suppose the "no good deed goes unpunished" step that would inevitably follow the addition of this feature is that I'd discover that actually I want to be able to use some of these property group types, but it would actually be convenient to set one of the sets directly. E.g., extensionMethodsWorkaroundTestRun is allOf testRun, bloatTestResults, and buildResults, but I might have only a testRun and a buildResults handy, and would want to set the bloatTestResults indivdually. The problem with that would be a combinatorial explosion of all the individual parts you may or may not have, so in practice, I think the answer would be "Either go back to the deconstruct-the-whole-thing approach, or wrap the bit you don't yet have in bloatTestResults form as a bloatTestResults before passing it to this chunky Create.

[StephenHodgson]

I've also been pondering how to deal with this as well. I thought an interface of some kind would be beneficial, that way the composition is additive.

But this library builds up partial classes, so unsure how that impacts this idea.

[mwadams]

I am considering:

Create() as-is then

Apply(X value), Apply(Y value) so it becomes multiple calls to apply the additional values, compositionally.

It's not that inefficient.

I'm also considering the vNext "alternate" generator with a mutable builder model for creation; that lets us provide those Create() and Apply() methods on our builder which also deals with the efficiency issue.

In this Apply model, I am assuming it would be more intuitive to provide "latest wins" semantics, although that is less efficient than "once it is set it is set".

(This is specifically what I am wrestling with right now in vNext.)

[mwadams]

My current thinking is a static Create() as-is that applies the "base" requirements then instance Apply() overloads for each of the allOf, anyOf and oneOf types.

I choose "Apply" as these are "applicators" in JSON Schema parlance.