someOfs with many options are hard to create by hand

[provokateurin]

An anyOf like https://github.com/nextcloud/neon/blob/4490e77d3b1d5e98a846ae5b178583d030c6bfef/packages/nextcloud/lib/src/api/core.openapi.dart#L9437 is really hard to create by hand because you need to explicitly set every option. Not using records would solve this as all empty fields could be left out.

[Leptopoda]

Should we really treat this as a bug?

[provokateurin]

I didn't know a better label, you can also remove it

[Leptopoda]

Let's consider this for the next release

[provokateurin]

For the release that is coming up this week or for the release after that? If it is the latter then please add it after we have made the upcoming release.

[Leptopoda]

I'll try to draft an idea today. If it fits we can still pull it into the next that is coming up. But it's not a blocker.

[Leptopoda]

Ok My initial idea was to add a separate helper constructor to one of our extension methods that takes a dynamic value, switches over the runtimetype and assigns it to the right field(s). But then it looks like we end up at the start, trying to build custom objects out of records.

Should we move back to classes (needing to wrap every object)?

[provokateurin]

I was thinking of a extension that adds a constructor that has all the fields, but set to null by default. Then it is very easy to add a single value and we wouldn't have a major rework and breaking change.

[Leptopoda]

There are two things to consider:

1. the constructor/static method will be in the extension thus you'd need to call SomeTypte$Extension.fromValue()

2. 1231

[provokateurin]

I'd be fine with calling the extension. Do you think it is easier to implement the discriminator with classes? Afaict it would also make the oneOf/anyOf validation easier, right?

[Leptopoda]

Do you think it is easier to implement the discriminator with classes?

Let's say it the other way. I do not think that it is even possible for records (at least not without a lot of hacks).

[provokateurin]

Ok, then let's go with classes again?

[provokateurin]

It would also be great to have good error messages for oneOf, because currently the error message doesn't help in debugging the problem. In case something goes wrong the serialization errors of all sub types should be displayed.