Is there anyone with a deep knowledge of Kotlin generics who could help me out with the API for <#CC...

# announcements

[dmcg]

Is there anyone with a deep knowledge of Kotlin generics who could help me out with the API for #CCYE00YM6? I’m trying to find the least worst solution to a co/contravariance conundrum.

[robstoll]

what's your problem?

[dmcg]

I want to annotate nodes in a tree with transforms that will be applied to that node.

[dmcg]

The NodeTransform is https://github.com/dmcg/minutest/blob/14365f101a74b805ea0d406c0fd28968f4b3511d/core/src/main/kotlin/dev/minutest/NodeTransform.kt - invariant in T

[robstoll]

do you modify the node during transformation or do you create a new node? If you don't change the node, then use can use site variance => next: (NodeTransform<out F>

[dmcg]

I don't change the node

[dmcg]

I think I did try site variance, but maybe not there!

[dmcg]

The annotations need to be in interface TestAnnotation<in F>

[dmcg]

as the transform can only apply to more general types

[robstoll]

I guess you could even use out for NodeTransform if they don't modify

[robstoll]

or what is the reason that made T invariant?

[dmcg]

Is this something that you have time to screen share over - I can give you a tour?

[robstoll]

nah unfortunately I don't (at least not now)

[dmcg]

I'm in no rush. If you can pick a ZonedDateTime I can fit around you and make sure that I'm up to speed on what has worked and what hasn't

[robstoll]

OK, I see and let you know. In the meantime, could you show me a use case where you are using the transformation

[dmcg]

That's grand. You could look at https://github.com/dmcg/minutest/blob/master/core/src/test/kotlin/dev/minutest/examples/experimental/SkipAndFocusExampleTests.kt - that shows the test annotations SKIP and FOCUS. The essential issue is reconciling the contravariant TestAnnotation with the invariant NodeTransform.

[dmcg]

https://github.com/dmcg/minutest/blob/master/core/src/main/kotlin/dev/minutest/experimental/TransformingAnnotation.kt is where my lack of prowess hits the fan.

[robstoll]

is the type of the node of any interest during transformation?

[robstoll]

the F in https://github.com/dmcg/minutest/blob/master/core/src/main/kotlin/dev/minutest/experimental/TestAnnotation.kt#L12

[dmcg]

I would be nice - I have places like https://github.com/dmcg/minutest/blob/master/core/src/main/kotlin/dev/minutest/experimental/flattening.kt where knowing the type allows some clever transformations

[robstoll]

just asking, sometimes we make the problems harder then they need to be 😄

[dmcg]

That sounds like my career

[dmcg]

I wonder if I should start from interface NodeTransform<F, F2: F>

[robstoll]

(node as? Context<Sequence<F>, F>) does not seem like you really use F at all. Or am I wrong?

[robstoll]

meaning you could replace F with * and have the same functionality

[dmcg]

Probably true there - but it's the Sequence<F> that corresponds to the F in the NodeTransform

[robstoll]

Well, theoretically but you are using an unchecked cast which means F could also be something completely different

[dmcg]

That's why it's private within TestContextBuilder<Sequence<F>, F>.flatten() - it's safe there

[dmcg]

F isn't important in the flattening, what is important is that the Context has a parent fixture of Sequence<F> and yields individual Fs

[robstoll]

but you don't know this. if you cast to Context<Sequence<F>, F> you only know that it is Context but it could also be Context<Int, String> and would still succeed

[dmcg]

But you're asking excellent questions - definitely the person for the job

[robstoll]

meaning it would fail at runtime

[robstoll]

and thus you could also remove the type parameter all together, you don't get any additional safety like this

[dmcg]

Ah yes, another logical step - TestContextBuilder<Sequence<F>, F> builds the Context

[dmcg]

that the transform is applied to

[dmcg]

So within that extension method we do know that the type of the Context is Context<Sequence<F>>, F>

[dmcg]

https://github.com/dmcg/minutest/blob/master/core/src/test/kotlin/dev/minutest/experimental/AnnotationVarianceTests.kt shows some of my experiments in the area

[robstoll]

I would try to get rid of all UNCHECKED_CAST. If you cannot, then there is no point of having a type parameter in the first place

[robstoll]

I'll see, maybe I get some time off in the afternoon so that I can have a closer look

[dmcg]

I'm trying 😉

[dmcg]

Really appreciate it. I work from home, so ping me any time that's convenient