oh ok

what about

“$(\\\”.results\\\”)”

@User uploaded a file: Untitled

so that the escaping is not just for the language level but also down to the transpiler

as I said, just guessing here

there should be some func for this

sorry I’m out then 😄

Anyone using kotlinx immutable (persistence) collections?

e.g.

listOf()

?

Like this: https://discuss.kotlinlang.org/t/kotlinx-collections-immutable-v0-1-has-been-published/2403/2

far from it 😞

@qwert_ukg don't worry too much 😉, my .NET experience tell me - that feature not popular in OOP languages.

Interesting what Erik Meijer will talk about Kotlin on KotlinConf? He is very interesting person - worked at MS Research (on LINQ) and contributed to Haskell. Maybe he bring some Haskell to Kotlin 😏

I like Functional Programming in Kotlin style 🙂

I was checking it out a lot here https://github.com/MarcinMoskala/mctsWonders/tree/master/src/kotlinwonders/functions

@marcinmoskala what you think about this feature https://discuss.kotlinlang.org/t/imports/1571/2 ?

I agree that current mechanism where you can import function as with name change is pretty wired 😕 and I would prefer import some package and name it

Currently it looks this way:

import func1.doSth as f1
import func2.doSth as f2

fun main(args: Array<String>) {
    f1()
    f2()
}

And when I am naming the function then I am doing it for reason. I don’t want anyone to use it with different name. It is really confusing. In case of name conflict I would prefer to prefix function with some name that will tell which function is that.

So I agree

@mg6maciej ?

I never found myself needing to rename functions via imports. Maybe I just create functions with too descriptive names and they don't collide.

BDW me too xP But I think that this can take place when more and more libs will be in Kotlin.

I'm not a big fan of using more and more libs even if people create them. I've not used RxKotlin for example. RxJava is fine.

But also I think that there is a problem with all this public functions. I think that there are cousing confusion because when the project is growing then there is more and more function you can use and it is hardet to guess which one are methods, which are from extension and which are public. I think that there should be in some point discussion about creating some conventions.

"Using more and more libs" is what happens in Ruby community. It's interesting to see how people add big dependencies when they need on function. In Android I've seen that happening with Guava.

Then maybe we should think if we really need Kotlin functions or we want to using something JVM specific like static functions, i.e. methods on object in Kotlin.

We had a conversation on this with Manhattan project. https://github.com/evanchooly/manhattan/blob/master/src/main/kotlin/com/antwerkz/manhattan/SystemProperty.kt and in the end we all agreed that having object there is good.

@mg6maciej Are you writing all code in functions (FP) or you use OOP with "helper functions". If your code consists from classes on 90% - it's not your problem (methods already limited by class scope).