PersistentSetMultimap?

[nornagon]

Guava's ImmutableSetMultimap is a convenient wrapper around ImmutableMap<K, ImmutableSet<V>>. It would be awesome to have a similar convenience in Paguro!

[GlenKPeterson]

Good suggestion! The "Comparison to a Map of Collections" in Google's Multimap explained to me what it's good for (I've never used one).

I'm currently split between converting the entire project to Kotlin and getting pieces of it incorporated into Kategory. I'm not sure of the ultimate relationship to Kategory. I think the Kotlin conversion and Kategory work are a higher priority because they set the over-all direction of the project. I may have to make changes to use slightly different interfaces than Paguro uses now. Your request is currently number 3 in my queue, but 1 and 2 are pretty big, so it will probably be months, (plural) not days or weeks before I can do this, but it's on the roadmap.

[nornagon]

Rapidly escaping the scope of this issue, but it would be awesome if the various pieces of paguro were separate maven artifacts, so that one could depend on just the persistent collections without pulling in everything.

I also hope that if the project is rewritten to target kotlin that Java remains a first-class client of Paguro :) On Tue, Oct 17, 2017 at 17:15 Glen K. Peterson notifications@github.com wrote:

Good suggestion! The "Comparison to a Map of Collections" in Google's Multimap https://google.github.io/guava/releases/19.0/api/docs/com/google/common/collect/Multimap.html explained to me what it's good for (I've never used one).

I'm currently split between converting the entire project to Kotlin and getting pieces of it incorporated into Kategory https://github.com/kategory/kategory. I'm not sure of the ultimate relationship to Kategory. I think the Kotlin conversion and Kategory work are a higher priority because they set the over-all direction of the project. I may have to make changes to use slightly different interfaces than Paguro uses now. Your request is currently number 3 in my queue, but 1 and 2 are pretty big, so it will probably be months, (plural) not days or weeks before I can do this, but it's on the roadmap.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GlenKPeterson/Paguro/issues/21#issuecomment-337418151, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKjANZ56CBdauOjTqATPuEtyKZMhzzdks5stUMggaJpZM4P83__ .

[GlenKPeterson]

I've been getting the impression that the persistent collections as a separate artifact would be more popular than when bundled with other functional programming tools. So I'm thinking about how best to make that happen already. Good to know there's another vote for that.

If you like Paguro, you're probably going to like Kotlin. If you haven't played with it, I encourage you to try it. It has rapidly become my favorite language. It also compiles to JavaScript, so that opens even more doors.

Kotlin functions already wrap checked exceptions. Kotlin has data classes which make tuples much less useful. Kotlin's stream/transform is pretty sweet and already assumes unmodiafiability. Some of those Paguro-Java features might be stripped off in the Kotlin version. So it sounds like the part you might lose is the part you don't want! Again, if you like those features, you may find yourself switching to Kotlin for those reasons, Paguro aside.

For the stand-alone collections I don't think Java users are going to know whether Paguro is written in Java or Kotlin. The 2-way compatibility between the two languages is excellent. Not perfect, but really, really good.

It's possible that Java programmers using Paguro-Kotlin would get Kotlin's stream API and maybe access to some other Kotlin features. I don't know. Kotlin's stream API is actually really nice. It assumes unmodifiable collections. It's simple and easy to learn. Kotlin's Extension Functions let you add .sum() only to streams of type Number. Again, not sure how that will come across in Java, but that's going to allow much more/better functionality without much more code.

So, that's my Kotlin ad for the day. I should get a commission from JetBrains! I'm not affiliated with them in any way.

[nornagon]

Thanks for the ad, but I already sold my soul to Scala :) On Wed, Oct 18, 2017 at 11:45 Glen K. Peterson notifications@github.com wrote:

I've been getting the impression that the persistent collections as a separate artifact would be more popular than when bundled with other functional programming tools. So I'm thinking about how best to make that happen already. Good to know there's another vote for that.

If you like Paguro, you're probably going to like Kotlin. If you haven't played with it, I encourage you to try it. It has rapidly become my favorite language. It also compiles to JavaScript, so that opens even more doors.

Kotlin functions already wrap checked exceptions. Kotlin has data classes which make tuples much less useful. Kotlin's stream/transform is pretty sweet and already assumes unmodiafiability. Some of those Paguro-Java features might be stripped off in the Kotlin version. So it sounds like the part you might lose is the part you don't want! Again, if you like those features, you may find yourself switching to Kotlin for those reasons, Paguro aside.

For the stand-alone collections I don't think Java users are going to know whether Paguro is written in Java or Kotlin. The 2-way compatibility between the two languages is excellent. Not perfect, but really, really good.

It's possible that Java programmers using Paguro-Kotlin would get Kotlin's stream API and maybe access to some other Kotlin features. I don't know. Kotlin's stream API is actually really nice. It assumes unmodifiable collections. It's simple and easy to learn. Kotlin's Extension Functions let you add .sum() only to streams of type Number. Again, not sure how that will come across in Java, but that's going to allow much more/better functionality without much more code.

So, that's my Kotlin ad for the day. I should get a commission from JetBrains! I'm not affiliated with them in any way.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GlenKPeterson/Paguro/issues/21#issuecomment-337690063, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKjAClvpOKGw5FC4-B3qoWFFFNqsC2eks5stkdGgaJpZM4P83__ .

[nornagon]

(Glad to hear you're already considering breaking out the persistent collections! Let me know if there's any way I can help :)) On Wed, Oct 18, 2017 at 11:46 Jeremy Apthorp nornagon@nornagon.net wrote:

Thanks for the ad, but I already sold my soul to Scala :) On Wed, Oct 18, 2017 at 11:45 Glen K. Peterson notifications@github.com wrote:

I've been getting the impression that the persistent collections as a separate artifact would be more popular than when bundled with other functional programming tools. So I'm thinking about how best to make that happen already. Good to know there's another vote for that.

If you like Paguro, you're probably going to like Kotlin. If you haven't played with it, I encourage you to try it. It has rapidly become my favorite language. It also compiles to JavaScript, so that opens even more doors.

Kotlin functions already wrap checked exceptions. Kotlin has data classes which make tuples much less useful. Kotlin's stream/transform is pretty sweet and already assumes unmodiafiability. Some of those Paguro-Java features might be stripped off in the Kotlin version. So it sounds like the part you might lose is the part you don't want! Again, if you like those features, you may find yourself switching to Kotlin for those reasons, Paguro aside.

For the stand-alone collections I don't think Java users are going to know whether Paguro is written in Java or Kotlin. The 2-way compatibility between the two languages is excellent. Not perfect, but really, really good.

It's possible that Java programmers using Paguro-Kotlin would get Kotlin's stream API and maybe access to some other Kotlin features. I don't know. Kotlin's stream API is actually really nice. It assumes unmodifiable collections. It's simple and easy to learn. Kotlin's Extension Functions let you add .sum() only to streams of type Number. Again, not sure how that will come across in Java, but that's going to allow much more/better functionality without much more code.

So, that's my Kotlin ad for the day. I should get a commission from JetBrains! I'm not affiliated with them in any way.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GlenKPeterson/Paguro/issues/21#issuecomment-337690063, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKjAClvpOKGw5FC4-B3qoWFFFNqsC2eks5stkdGgaJpZM4P83__ .

[GlenKPeterson]

I made a new issue for the collections: #22