<@U12AGS8JG> <@U019YR8UJ8L> any opinions on <https...

# kotest-contributors

[Emil Kantis]

@sam @mitch any opinions on https://github.com/kotest/kotest/pull/3358? Good idea to add?

I'm also a bit bothered by the naming. I would like to have something like:

val companyDepartmentArb = Arb.bind<CompanyDepartment>(
  Location::class to myLocationArb,  
  Person::name to Arb.string(codepoints = Codepoint.alphanumeric()),
  Person::age to <http://Arb.int|Arb.int>(0..120),
)

Right now you'd have to do:

val companyDepartmentArb = Arb.bind<CompanyDepartment>(
  providedArbs = mapOf(Location::class to myLocationArb),  
  arbsForProperties = mapOf(
    Person::name to Arb.string(codepoints = Codepoint.alphanumeric()),
    Person::age to <http://Arb.int|Arb.int>(0..120),
  )
)

Plus the naming feels a bit off. providedArbs doesn't say how it's different from arbsForProperties , but changing it means breaking backwards compat.. Perhaps easiest to just add new methods altogether and deprecate the current ones, but that's also a bit invasive..

[LeoColman]

If they're not insanely different/confusing/broken we can add the new options and keep them as aliases

[sam]

I like the first idea.

[mitch]

+1 I think the first idea is really clean

[Emil Kantis]

Downside is it's strict on the order of arguments. Would be something like. Perhaps not an issue though

fun Arb.bind(
  vararg classArbs: Pair<KClass, Arb>, 
  propArb: Pair<KProperty, Arb>,
  vararg propArbs: Pair<KProperty, Arb>,
)

Generics omitted for readability.. 🙂

[Emil Kantis]

Another option.. trying to make it order-independent. 🙂

Untitled.cpp

[LeoColman]

I don think you can have 2 varargs

[Emil Kantis]

you're right 🙂