versionedDependency decorator is confusing

[tjprescott]

Feedback from the most recent ARB review was that the @versionedDependency decorator was confusing.

@versionedDependency([[Versions.A, Azure.Core.Versions.v1_0_Preview_1]])

This was interpreted as the spec depending on itself. Additionally, what if a spec depends on specific versions of other libraries? Does it need to look like this?

@versionedDependency([[Version.A, Azure.Core.Versions.v1_0_Preview_1], [Version.A, Azure.Foo.Versions.v1_0_Preview_1]])```

A possible alternative would be to use a dictionary with the key as the spec version and an array of dependencies.

@versionedDependency({
  Version.A: [
    Azure.Core.Versions.v1_0_Preview_1,
    Azure.Foo.Versions.v_1_0_Preview_1
  ],
  ...
})

[markcowl]

The design is that, if there were multiple library dependencies, there would be multiple decorators. I think the proposal is logical, though.

[tjprescott]

I think folks were confused by the tuple which looks like an array so they assumed it was an array that happened to have two things in it. Dictionary was suggested because it's a little clearer at a glance that the spec version as a key is special and separate from everything else, which are the actual dependencies. With a tuple, it looks like both things are the same (dependencies)

[timotheeguerin]

yeah the tuple was the only way we could do with enums for versions. I originally was thinking of something similar to what you have but we can't have enum member as model keys.(at least for now)

[markcowl]

pri: 2

[timotheeguerin]

Alternate syntax we could do right now: Make the version mapping to be in a nested tuple instead of flattened with the key.

@versionedDependency([
  [Version.A, [
      Azure.Core.Versions.v1_0_Preview_1,
      Azure.Foo.Versions.v_1_0_Preview_1
    ],
  ],
  [Version.B, [
      Azure.Core.Versions.v1_0_Preview_1,
      Azure.Foo.Versions.v_1_0_Preview_1
    ],
  ],
])

[tjprescott]

I almost feel like a nested tuple would be worse... is the enum as key limitation Cadl or TS?

[timotheeguerin]

Cadl, object can only have string keys(well identifier or StringLiteral)

[timotheeguerin]

In TS you can do that this way, it would probably look similar if we allowed it

[tjprescott]

I'm curious why Foo.a would need to be in brackets? Why not just:

const a = {
   Foo.a: [Foo.a, Foo.a],
};

[timotheeguerin]

meaning that you want to get a reference here and exactly Foo.a is not the key.

alias MyStr = "my-key";

model Foo {
  MyStr: int32;   // Here that means the property is actually `"MyStr"`
  [MyStr]: int32; // Here means the property will be `"my-key"`
}

same concept in TS.

[tjprescott]

Weird, but okay :)