https://kotlinlang.org logo
Join Slack
Powered by
but if I want to keep that interface (not a HOF), ...
# getting-started
a
but if I want to keep that interface (not a HOF), e.g. because of Spring (AFAIK you cannot inject implementation classes based on HOF), then what? Edit: this is an issue because when using Spring, I need interfaces (and cannot use HOF) and in tests I must use this verbose syntax for Kotlin interfaces (for legacy Java interfaces the short syntax - lambda works great)
😭 1
t
you can still write the interface in java, java and kotlin can be mixed in the same project. btw, I don't really get your example, at least in my experience Spring is also responsible of instatianting the actual object to inject, so you would probably have
Copy code
interface Something

@Component
class Impl : Something
in most situation. The problem you have is when you want to create anonymous implementations, but that is not really the pattern in Spring, is it?
a
The case is as follows, Kotlin says you should not create interfaces with just one method, use HOF instead, e.g.: https://kotlinlang.slack.com/archives/C0B8MA7FA/p1573016869426700?thread_ts=1573013718.426300&cid=C0B8MA7FA
because you can't do SAM for Kotlin interfaces (even though you can for Java interfaces)
and it would be extremely useful to have the same syntax for Kotlin interfaces
the reason is e.g. Spring Framework. If you use Spring, you have plenty of such interfaces
I see this issue raised over and over again, on Slack, on Stack Overflow, on Kotlin tracker (main thread: https://youtrack.jetbrains.com/issue/KT-7770)
and I'm surprised, because I see that generally Kotlin is very focused on easiness of use, developer friendliness, not "purity" or "correctness" like some other languages
The reason why this is an issue with Spring is that when you have such interfaces, you usually also provide anonymous implementations in tests
t
do you? why not using a mocking framework (being mockito or mockk)?
a
because there is no need for mockito. When I write my own "mocks" (BTW rather stubs or dummies) it's simpler, more readable, less magic
I see no real benefit of mocking frameworks in well designed, testable systems. In fact I believe that eventually they do more harm than good
by allowing you for bad design and introducing additional "magic" (read accidental complexity) to your project
t
I am not arguing, in the end coding is a matter of taste and tools. mocking frameworks are a tool, if you don't feel the need, don't use them. but kotlin is a tool as well, if it is in your way, don't use it. again, you can just extract the interface in a java package. otoh, if you are talking about stubbing the behavior of an interface, you probably just need a factory class, as you probably don't need to get different output for the interface, rather than a success and an error. then, it is not too much of a pain having a more convoluted syntax
that being said, don't take everything uncle bob says as the bible, though I think you are not (you wrote you don't see benefit, so you seem to have your own opinions), I follow him but I think he is a bit detached from the real world
a
oh, thank you for your appreciation, 
you seem to have your own opinions
I think our discussion should stop here.
you judge people knowing nothing about them instead of giving rational arguments
t
I meant it seems you are not repeating what others said/wrote but built your own opinions, which is not an insult (imo, if you got it that way, it was not my intention)
a
the issue is, which I'm afraid you don't seem to understand, here we are all for technical discussions rather than for reading your general opinions about Uncle Bob (
he is a bit detached from the real world
), about myself or anybody else. I don't care about your judgment of my or anybody's else opinions ownership. If you have a rational technical argument you want to share, feel free. If you just have your judgment about others or their opinions - just keep it for yourself, it's that simple.
t
again, not gonna argue. going back to the original point (and I am not defending kotlin choices, if they implement sam conversion for kotlin interface good), I proposed technical alternatives to you to alleviate your pain: - mocking frameworks - test factories (to reduce the number of times you have to create your interface stubs) - turn kotlin interfaces used in spring into java interfaces feel free to look at them or wait for (if) sam conversion. but agree, I think we can end the discussion, I don't know how else to help you
a
thank you for these 3 technical solutions, they were helpful
10 Views
Open in Slack
PreviousNext
Powered by