Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Artem Bilan
    @artembilan
    Sorry for typos, though. “Call it” and “thank you for” 😜
    Right, I saw that yesterday
    Jeansen
    @Jeansen
    :D
    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
    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
    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