Add "combine" or "merge" operator for models

[johanste]

Something that I have missed is the ability to combine models outside of spread operators. One example of a (unrelated) language is jsonnet's object combine operator (see inheritance and nested field inheritance the sections).

To illustrate a bit what I'm thinking:

model Base {
  id: string;
  etag?: string;
  apiVersion: string;
}

model Overrides {
  id: int32;
  description?: string;
  apiVersion: never;
}

model Combined is Base + Overrides;

/*
// Resulting model:

model Combined {
  id: int32;
  etag?: string;
  apiVersion: never;
  description?: string;
}
*/

As indicated, the resulting model is not a subtype of either operands, the order of attributes could be preserved (although there is an argument to be made that overriding attributes should move later), decorators (not shown) are not merged etc.

I can think of a couple of places in azure core where this would be useful and simplify our life.

Playground Link

[timotheeguerin]

is the goal here not simply just have multiple model is

[johanste]

I don't think so. I wouldn't expect decorators on Base or Overrides to be applied to Combined. But I do want the property conflicts that would result in doing:

model Combined {
  ... Base;
  ... Overrides;
}

...with last-in-wins semantics...

[bterlson]

I am missing something obvious here, but... how is this different from spread?

[timotheeguerin]

with spread you cannot override properties, here proposal is to have something that would behave like TS object spread

[bterlson]

Ahh right. I don't remember why we made our spread not allow duplicates, but is that something we could change also? I am allergic to adding yet another composition mechanism.

[timotheeguerin]

Yeah I think the one thing though is that right now A & B and {...A, ...B} are exactly the same, I feel like A & B shouldn't be overriding(it merge in typescript)

[timotheeguerin]

Noting that this behavior of overriding is not possible in the typescript type system( as far as I remember), you can override object properties this way but not interface memebers

[bterlson]

The type system does allow it in the sense that runtime spreads do the override calculations in the type system, but you can't declare such types (there is an issue tracking it that has been open for some time).

If the only real justification for spread not overriding previous properties is to maintain alignment with intersection, then I would be fine updating spread to override. Intersection should probably intersect same-named properties too, and that would definitely not make sense for spread...

[johanste]

One would also have to decide what to do for nested properties. You commonly want json-merge-patch like merge as opposed to replace-at-top-level. And controlling this would be the main reason to introduce another merge operator.

[fuunnx]

Hi, what about somethings like that ?

model Base {
  id: string;
  etag?: string;
  apiVersion: string;
}

// option A1 : new "@override" decorator on the properties (OK, except "override" is not actually a metadata)
model Combined {
  ...Base;
  @override id: int32;
  description?: string; // overriding a non existent property would print an error
  @override apiVersion: never;
}

// option A2 : new "override" keyword on the properties (great, but introduces a new keyword)
model Combined {
  ...Base;
  override id: int32;
  description?: string; // overriding a non existent property would print an error
  override apiVersion: never;
}

// option B1 : new "@override" decorator on the model (not my fav)
@override
model Combined {
  ...Base;
  id: int32;
  description?: string;
  apiVersion: never;
}

// option B2 : new "extends" keyword (not my fav, and introduces a new keyword)
model Combined extends Base {
  id: int32;
  description?: string;
  apiVersion: never;
}

// or something in between ?

---

Also:

One would also have to decide what to do for nested properties. You commonly want json-merge-patch like merge as opposed to replace-at-top-level. And controlling this would be the main reason to introduce another merge operator.

I could live without as I live without it everyday in the JS ecosystem :D

But yeah, could be great (another keyword ? ^^)

---

Kindly, in the hope of reviving this discussion for a top needed feature