spring-projects/spring-integration

Jeansen

@Jeansen

https://discuss.kotlinlang.org/t/static-extension-methods-for-java-classes/2190

Artem Bilan

@artembilan

Sorry for typos, though. “Call it” and “thank you for” 😜

Right, I saw that yesterday

Jeansen

@Jeansen

Artem Bilan

@artembilan

This one works, too

IntegrationFlows.from(MessageProcessorMessageSource { "bar" }, Consumer { it.poller { it.fixedDelay(10).maxMessagesPerPoll(1) } })

, if you are still interested in something shorter :smile:

Jeansen

@Jeansen

Thx. And yes, I am :smile:

Artem Bilan

@artembilan

@Jeansen , @glammr1 , WDYT about pursuing a syntax like this:

.convert<String>()

instead of

.convert(String::class.java)

Unfortunately it made me to write this code:

inline fun <reified T> IntegrationFlowBuilder.convert(): IntegrationFlowBuilder = convert(T::class.java)

inline fun <reified T> IntegrationFlowDefinition<*>.convert(): IntegrationFlowDefinition<*> = convert(T::class.java)

Just because there is easy way to deal with recursive generics in Kotlin extensions for Java classes

I mean just because of this in Java right now:

public abstract class IntegrationFlowDefinition<B extends IntegrationFlowDefinition<B>> {

There are many other IntegrationFlowDefinition methods which could be reified :smile:

Bob Glamm

@glammr1

.func<T>() seems to be a common Kotlin replacement for Java's .func(Class<T>) in the libraries I have looked at

Artem Bilan

@artembilan

Good. Thanks for the feedback, @glammr1 !

How do you know if there is a way to hide generic or really infer it from upstream?

I tried like this:

inline fun <reified T, B: IntegrationFlowDefinition<B>> B.convert(): B = convert(T::class.java)

But it requires from me the second generic specification during typing

That's what I mean with recursive generics issue in Kotlin

https://medium.com/@jerzy.chalupski/emulating-self-types-in-kotlin-d64fe8ea2e62

The other downside of this solution is the usage from Java side. The extension functions are desugared into static utility methods, so from Java, you won’t be able to chain the methods.

Bob Glamm

@glammr1

I don't know enough about type systems to answer that question

Jeansen

@Jeansen

Me neither ;-(

But I think most use-cases are anyway java to Kotlin and not the other way around ;-)

Bob Glamm

@glammr1

I do know that I have seen recursive types done well only in ML-type languages like Haskell

Artem Bilan

@artembilan

OK. No problem :smile:

Bob Glamm

@glammr1

Kotlin, as far as I understand its type system, does not implement recursive types well

My guess on reified with inline is that the compiler drops in the AST for inline <reified...>... at the use site and expands the template with the given type to do the reification

Jeansen

@Jeansen

Yes, IIRC I read they are not as "optimistic" with recursive types as e.g. scala

Bob Glamm

@glammr1

^^ I am interested to see if Dotty handles recursive types more like Haskell

Jeansen

@Jeansen

I've never done anything in Haskell .... maybe I should ;-)

Bob Glamm

@glammr1

Tagless final + immutable data + referential transparency seems compelling to me, whether it's in Scala/cats, Kotlin/arrow, or Haskell

but I have found it to be a steep learning curve with plenty of rabbit holes to dig into

Artem Bilan

@artembilan

i think this is not bad, right?

it.convert<TestPojo> { it.id("kotlinConverter") }

Having an implementation like this:

inline fun <reified T> IntegrationFlowDefinition<*>.convert(
        crossinline consumer: (GenericEndpointSpec<MessageTransformingHandler>) -> Unit): IntegrationFlowDefinition<*> =
        convert(T::class.java)  { consumer(it) }

And I think it.convert<TestPojo> {} is good, too.

It is great just have a single inline then! :smile:

Bob Glamm

@glammr1

API syntax seems pretty reasonable

Artem Bilan

@artembilan

Here is a PR, BTW: spring-projects/spring-integration#3060

Jeansen

@Jeansen

Yes, I like it. I also read a bit into this self article regarding self types. Very interesting ... :grinning:

I have done (without knowing it) something similar (but simpler with logging:

fun <T : Any> T.logger(): Logger = getLogger(javaClass)

Which you'll find here: https://www.baeldung.com/kotlin-logging

Artem Bilan

@artembilan

Right. That's good one and reminds me all those additions in Groovy

Although we can't do something like this on the Framework level

It is going to be a bit dangerous for end-users of our library

Where communities thrive

People

Repo info

Activity