Comments (6)
GlenKPeterson
commented on June 3, 2024
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.
from paguro.
nornagon
commented on June 3, 2024
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__>
.
from paguro.
GlenKPeterson
commented on June 3, 2024
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.
from paguro.
nornagon
commented on June 3, 2024
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__>
.
from paguro.
nornagon
commented on June 3, 2024
(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__>
> .
>
from paguro.
GlenKPeterson
commented on June 3, 2024
I made a new issue for the collections: #22
from paguro.
Related Issues (20)
- More Benchmarks vs. pCollections (was: incorrect comparison with pCollections) HOT 5
- tag for 3.0.16? HOT 6
- Findbugs reports lots of issues HOT 2
- Support split(0) and split(size) HOT 6
- No way to iterate over maps without allocation HOT 2
- Concatenating RrbTree's with different element types gives ArrayStoreException HOT 5
- Remove usages of Array.newInstance() to enable native compilation HOT 7
- Possible bug in immutable RRB tree implementation HOT 12
- Confusing comment in RrbTree implementation HOT 2
- get fails for some indexes after joining two RrbTree vectors of certain sizes HOT 1
- Support Request: Creating a PersistentVector HOT 1
- Support Request: Threadsafety of PersistentHashMap HOT 11
- Make map creation less verbose HOT 2
- How to use Paguro with Java stream? HOT 1
- Collector implementations of the Paguro collections
- ImList, MutList - example for best practice of inserting an element before an existing element HOT 3
- MutVector<F>#replace() problem HOT 5
- ClassCastException after updating from 3.6.0 to 3.7.1 HOT 1
- Best practice for "inplace" sort() method on MutRrbt HOT 2
- Lazy/non-lazy concat() in PersistentHashSet versus PersistentVector HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from paguro.