model extends/is record<>

[msyyc]

Cadl Ranch Contribution Checklist:

• I have written a scenario spec
• I have meaningful @scenario names. Someone can look at the list of scenarios and understand what I'm covering.
• I have written a mock API
• I have used @scenarioDocs for extra scenario description and to tell people how to pass my mock api check.

[changeset-bot]

🦋 Changeset detected

Latest commit: 47e84d8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@azure-tools/cadl-ranch-specs	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[lmazuel]

• I would not put this in inheritance. TSP uses "extends", but it's the concept of "additional properties". Inheritance is misleading here.
• I need a GET as well

[timotheeguerin]

note also extends vs is is different, you probably still want is. Extends will say i am inheriting a Record, is will just say I am a Record<string>

See the differently generated openapi
https://cadlplayground.z22.web.core.windows.net/?c=bW9kZWwgTcQGUmVjb3JkVW5rbm93biBleHRlbmRzIMYWPHXGFz4gewogIG5hbWU6IHN0cmluZzsKfQoK2EYyIGnfQsZC

I don't know how that affect generated client however but I could imagine something like that

class WithExtends extends Dictionary<string, string> {

  public Name {get; set;}
}


class WithIs implements IDictionary<string, string> {
  ... need to imploement dictionary interface
  public Name {get; set;}
}

[weidongxu-microsoft]

On swagger output of

model ModelRecordUnknown2 is Record<unknown> {
  name: string;
}

    ModelRecordUnknown2:
      type: object
      additionalProperties: {}

It does not have anything about "name"?

---

PS, Java uses composition (it is almost always a bad practice to inherit Map in Java).
E.g.

class WithWhatever() {
  string name;
  Map<String, Object> additionalProperties; // this does not serialize to JSON, but as a composition for properties except "name"
}

[msyyc]

note also extends vs is is different, you probably still want is. Extends will say i am inheriting a Record, is will just say I am a Record<string>

See the differently generated openapi https://cadlplayground.z22.web.core.windows.net/?c=bW9kZWwgTcQGUmVjb3JkVW5rbm93biBleHRlbmRzIMYWPHXGFz4gewogIG5hbWU6IHN0cmluZzsKfQoK2EYyIGnfQsZC

I don't know how that affect generated client however but I could imagine something like that

class WithExtends extends Dictionary<string, string> {

  public Name {get; set;}
}


class WithIs implements IDictionary<string, string> {
  ... need to imploement dictionary interface
  public Name {get; set;}
}

@timotheeguerin As weidong said, we shall encourage users extends instead of is otherwise users can't get expected output.

[msyyc]

• I would not put this in inheritance. TSP uses "extends", but it's the concept of "additional properties". Inheritance is misleading here.
• I need a GET as well

I add new folder record under type/model and also add GET case

[tadelesh]

@msyyc I prefer to add it under to type/property named with additional-properties. @timotheeguerin I have a question for Record<unknown>. From TSP type relations, it seems custom model with properties are derived from Record. It that mean all custom models are already support additional properties? What's the difference for an explicit Model extends Record<unknown>?

[timotheeguerin]

Hhm yeah seems like we have a bug in autorest and openapi3 emitter, those properties should not be dropped. I think the idea was there though that with is you have additionalProperties on the schema itself. Vs with extends it use an allOf.

I think the takeaway is mostly both can happen and I think we should recommend people to use the is variant. If you generate the same thing then maybe its ok

[timotheeguerin]

@msyyc I prefer to add it under to type/property named with additional-properties. @timotheeguerin I have a question for Record. From TSP type relations, it seems custom model with properties are derived from Record. It that mean all custom models are already support additional properties? What's the difference for an explicit Model extends Record?

there is a discussion on Teams about that

short answer, no models do not have additional properties in the TypeSpec system(I made a wrong statement before), we might need to update the type graph a little bit

model Foo { } !== model Foo is Record<unknown> {}

[msyyc]

@msyyc Yuchao Yan FTE I prefer to add it under to type/property named with additional-properties. @timotheeguerin Timothee Guerin FTE I have a question for Record<unknown>. From TSP type relations, it seems custom model with properties are derived from Record. It that mean all custom models are already support additional properties? What's the difference for an explicit Model extends Record<unknown>?

@tadelesh Make sense. I will move it to type/property/additional-properties

[msyyc]

@timotheeguerin @lmazuel @tadelesh @weidongxu-microsoft
Updated:
I understand that language emitter shall have same behavior for extends Record<> or is Record<>, I add test for both scenario.

[tadelesh]

some minor comment

[tadelesh]

some minor comment

[weidongxu-microsoft]

Make sure you've tested the mockapi in python.

[qiaozha]

LGTM

[tadelesh]

Though seems a little bit weird to give both is and extends example, but should all be valid cases for non-branding.

[lmazuel]

Was approved by enough smart people to remove my "require change" :)