top | item 32289304

(no title)

fmakunbound | 3 years ago

Perhaps that stance has changed over time. In Clojure, there's the clojure.string namespace just functions wrapping java.lang.String methods https://clojuredocs.org/clojure.string

discuss

order

casion|3 years ago

This is much more than "just wrapping". It allows strings to be used more readily with existing Clojure abstractions and/or allows idiomatic use without the need for being on guard to avoid reflection.

Notably, Alex didn't write this library and only has a minor contribution to it.

didibus|3 years ago

There's two cases where you'll see pragmatic wrapping:

1. Higher order usage. When functions would really benefit from being used in a higher order way, passed around as values, you'll see some of the Java methods wrapped so they can more easily be used as such, since you can't use Java methods in a higher order way. This would count as "can do it better", and it's the case for clojure.string.

2. For portability with Clojurescript. This is a more recent thing, but as Clojurescript usage grows, and code reuse between backed and frontend more common, there are certain basic methods Java interop was totally fine with that now benefits from being wrapped. This is the case for clojure.math.

moomin|3 years ago

I think the problem is that if you want to write code portable between clj and cljs, you’re gonna need a lightweight abstraction. With that said, I’m still not sure how exactly the maintainers feel about portable code, having written a portable http library.