PersistentSetMultimap? #21
Comments
|
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. |
|
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 ***@***.***> 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
<#21 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKjANZ56CBdauOjTqATPuEtyKZMhzzdks5stUMggaJpZM4P83__>
.
|
|
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 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. |
|
Thanks for the ad, but I already sold my soul to Scala :)
…On Wed, Oct 18, 2017 at 11:45 Glen K. Peterson ***@***.***> 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
<#21 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKjAClvpOKGw5FC4-B3qoWFFFNqsC2eks5stkdGgaJpZM4P83__>
.
|
|
(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 ***@***.***> wrote:
Thanks for the ad, but I already sold my soul to Scala :)
On Wed, Oct 18, 2017 at 11:45 Glen K. Peterson ***@***.***>
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
> <#21 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAKjAClvpOKGw5FC4-B3qoWFFFNqsC2eks5stkdGgaJpZM4P83__>
> .
>
|
|
I made a new issue for the collections: #22 |
Guava's ImmutableSetMultimap is a convenient wrapper around
ImmutableMap<K, ImmutableSet<V>>. It would be awesome to have a similar convenience in Paguro!The text was updated successfully, but these errors were encountered: