<https://blog.kotlin-academy.com/the-problem-with-...

# feed

[marcinmoskala]

https://blog.kotlin-academy.com/the-problem-with-extension-functions-dffd22eb5df9

[LeoColman]

Thanks for the articles!

[LeoColman]

Particularly, I've never seen those examples in a Kotlin codebase

[LeoColman]

And I think that if people are doing that, it's not a problem with extension functions, it's a problem with people and their dirty coding practices. We can't escape that

[thanksforallthefish]

I am always a bit in the middle, I know a language cannot provide a feature only for the positive use cases, once the feature is there it is there ripe for bad (or forced) use cases too. But it is also in human nature to try to find shortcuts and being very bad at assessing long time impact of some decisions which might look smart now but might bite in the future.

[thanksforallthefish]

otoh, a friend of mine is now working in go and he keeps telling me the language is so dry and limited you simply have to redo things over and over, I see the other side of the coin, opinionated language trying to avoid users mistake are no fun (pun intended)

[LeoColman]

I rather give the freedom to make good code with the possibility of making bad code. Crappy and macgyvers will always be around in any language, and I don't believe there is much we can do to prevent that

[thanksforallthefish]

probably not in the general case, but you can help people working with you teaching them. also, I like the macgyvers definition, it might be English is not my first language, but am laughing the wording 🙂

[LeoColman]

In my language(portuguese), there's is a beautiful word called "Gambiarra". The closest concept to it is "pulling a macgyver"

[LeoColman]

And there are codes that are full of those 😄

[altavir]

I agree with the problem description, but do not agree with the conclusion. Yes, Kotlin really wants some way to solve multiple receiver problem, but it certainly does not mean that one should avoid using extensions. On the contrary, we should discuss what is the best way to introduce multiple receivers. In kotlin reveivers are explicit, not implicit, so I do not see any problems here. Also I completely disagree with thi statement that member extensions are bad.

[marcinmoskala]

I think that Kotlin is great, but for MacGyvers we need some best practices. Our community is too big. It is not only a language for passionates. There are already many people who chose it because of money, who were forced to use it, or for whom it is their first programming language. They lack of education, but often not creativity. I’ve seen a lot of crazy shit in a variety of projects and I hope to make it better. I believe that Scala has bad name (as unreadable) because of some crazy ways how it is used by some developers. I want Kotlin to keep being loved by developers 🙂 I believe that this best practices are the best I can do.
@altavir I do not dislike extensions. Just see their limitation. Can you show me member extension that is good (except of DSL)? Would you like to see extension functions with multiple receivers?

[LeoColman]

I personally use extension functions for almost everything. Mainly when it will be something like fun foo(bar: Bar). Most of the times I can transform it into a private extension function fun Bar.foo() and operate with that. I think it reads much, much better

[marcinmoskala]

I agree for all top-level functions

[marcinmoskala]

Or most

[LeoColman]

I understand that when you follow all the other good practices, extension functions tend to be readable and understandable. And I understand your point that perhaps allowing everything may derail the train in most situations

[LeoColman]

I like that you mentioned that Kotlin is no longer (if ever) a thing for passionates about it

[LeoColman]

And that's one of the things people like about Java, the verbosity and limits won't allow much space for hacking

[altavir]

I wrote two articles about extension-based design in kotlin: https://proandroiddev.com/diving-deeper-into-context-oriented-programming-in-kotlin-3ecb4ec38814. There is also an article by Roman Elizarov. Of course, both are about libraries, but still one should not discard such a powerful tool. There could be some limitations for beginners though.