Why "use clojure.string instead of interop"?

[rkc-rkc]

From the doc ==>

(clojure.string/upper-case "bruce")

;; bad
(.toUpperCase "bruce")

But looking at clojure.string/upper-case

user=> (source clojure.string/upper-case)
(defn ^String upper-case
  "Converts string to all upper-case."
  {:added "1.2"}
  [^CharSequence s]
  (.. s toString toUpperCase))

it is but a call to interop. It will be nice to know why one is preferred over the other.

[bbatsov]

Two reasons:

• reads better (subjectively)
• portable across Clojure implementations. All interop calls tie you to the underlying platform.

[rkc-rkc]

* reads better (subjectively)

Style guide by definition is subjective and this is fine with me

* portable across Clojure implementations. All interop calls tie you to the underlying platform.

That had not crossed the mind. Thanks.
May I then suggest the title "Use platform agnostic methods to improve portability"

[bbatsov]

Yeah, I totally agree this should be formulated in a more generic manner.

[pauldorman]

It should be noted that in the case of upper-case, if you are writing code only for the JVM or JavaScript, the Clojure and ClojureScript implementations of clojure.string/upper-case are ostensibly the same, calling the native .toUpperCase method (Clojure CLR uses the differently named .toUpper native method).

So for most people .toUpper (and friends) are effectively portable, which perhaps makes it a less-than-ideal example for the interop vs built-in argument. I would also say that, to me at least, ".toUpperCase" is at least as readable as "upper-case".

Elegant and seamless interoperability is rightly touted as one of its outstanding features, so we shouldn't be afraid to use it, especially for trivial cases where you understand your target environment.

That said, a compelling counterargument what I have just said is that there's no actual benefit to using .toUpperCase over upper-case in terms of your program's runtime size or performance. Your code gets compiled into pretty much the same thing irrespective of what approach you use, so what we're really talking about here is how much we object to the extra keystrokes needed to use the Clojure implementation, either through requiring clojure.string or using the qualified clojure.string/upper-case form.

Personally, I've heard all the arguments [😁], and I think I come down on the side of using the provided Clojure functions.

[seancorfield]

In Clojure 1.12, this is (mostly) the difference between:

(String/.toUpperCase foo)
;; and
(str/upper-case foo) ; assuming `(:require [clojure.string :as str])` which a lot of nses have

I assume ClojureScript 1.12 would be the same (when it gets there), but I suspect not all clojure.string functions are implemented the same way for Java and JS, so I agree that picking a different example -- that isn't portable even across JVM/JS Clojure/Script -- would be a better example in this case.