there has to be a way to fake out the maven build

@evanchooly There is, I just upload an empty

-javadoc.jar

that part i get. what I'd love to have is some ... hook ... that would generate that as part of the release build.

mvn javadoc:jar

won't produce an empty jar if there are no java sources to parse.

Kobalt will happily generate one for you, even if you don't have any Java source files 😄

yeah. i should switch this to kobalt.

does anybody know the issue to convert

listOf

and

mapOf

to use immutable collections? I know I saw it but I cant find it now

I'd love them to be hooked up to pcollections (or some other persistent collection implementation)

I guess maybe what I really want is persistent collections in the std library and easy ways to create instances of them.

pListOf()

or some such name we can argue about at length. 🙂

@jkwatson what is the reason to have something like that in stdlib and not use a jar from maven?

I think to have them match kotlin standard patterns. And, encourage people to think about persistent collections as something for handling immutable data.

I work on immutable collections prototype, whose implementations are currently based on pcollections: https://github.com/Kotlin/kotlinx.collections.immutable. Soon it'll be published on bintray so you'll be able to experiment with it without building it locally.

With coroutines handling multithreading, the need for persistent collections is (even) less. They become a very niche feature and I don't think encouraging to use them is a good idea

Can you explain why you think that coroutines make the need for good immutable data structures less important?

@jkwatson I only only 2 reasons to want immutable collections when you already have read-only ones (like in Kotlin): to save memory and to avoid multithreading issues

If I use coroutines on few threads, synchronization becomes cheap and more effective than immutability

It is a hard call. When you start programming with coroutines you quickly adopt “share by communicating” style with actors and similar patterns. Now, if the stuff you want to share (send between coroutines) is represented in collections you’d better use persistent collections to avoid excessive defensive copying and reuse memory in case when one actor takes a collection of data, modifies it a bit, and sends to some next actor in the pipeline.

However, you more often share (send between coroutines) some user-defined data classes than collections. A that is the problem. There is no support for persistent data classes. You can emulate them using defensive copying with a handy

copy

function that is provided for

data class

, but that becomes tenious on complex data class hierarchies. However, that is a totally seperate #language-proposals discussion not related to stdlib.

Note, that in languages like Clojure this is not an issue. Every data structure in Clojure is a composition of collections. So you have persistent collections and boom — all your data sharing problems are solved at once. But I fail to see how persistent collections in Kotlin really make a big difference without support for persistent data classses.

@elizarov are you talking about "lenses", or something else?

Imagine how that looks when you start mutating nested data structures and your mutation logic becomes complex (like a typical business logic is). You can do this with lenses. You can even call the resulting code “beautiful”, but I bet that even yourself will be scratching your head on what it does and how it works in a month.

I looked up a couple of lenses examples, and somehow I fail to see the improvement you are talking about. Would you care to show me how your code above would be with lenses and why it is less readable / flexible ?

@elizarov Thanks for your thoughts. Yes, persistent data classes would be fantastic; I have struggled with building some way to do efficient immutable yet transformable data both in kotlin and in Java. Most of the time, I just bite the bullet and make copies of my data. This is fine for low-volume applications, but in a high-throughput scenario causes way too much garbage collection overhead.

also @voddan I couldn't disagree about immutable collections more. I can (and do) use immutable collections over mutable collections by default. The reason is because it typically starts to clarify what the rust guys would call "ownership semantics"; exactly who is adding data where becomes much more evident with persistent collections than mutable ones. Debugability also typically goes up when you can be certain that collection instances wont be changed. You do start to see some pressure on return types to keep up as what might, with mutable collections, be a modified-by-reference list now becomes a new returned list instance, meaning

fun someFunc(): Pair<SomeModel, List<OtherModel>>

becomes more common, but thats also a move to more pure functions which im totally in favor of. Unfortunately, when you want to use one of the ol'

java.concurrent.collections

or some other java-centric APIs I'm forced back into mutable land.

and anyways, while I'm glad I've got the community talking about this again, I still cant find the darn issue. Does anybody know where it is? I'm certain of read it before.

@groostav AFAIK there is no such issue in tracker, the closest one is https://youtrack.jetbrains.com/issue/KT-9659

@thomasnield has left the channel

this happens roughly once every 10 builds

maybe slightly related to https://youtrack.jetbrains.com/issue/KT-14771 ?