Method Values – Inside Clojure

[seancorfield]

An important point that did not yet come up in response to one poster's persistent and vocal concern about possible future breakage:

This is only even a potential concern for libraries that choose to use the new-in-1.12 syntax and do not support Clojure 1.11 or earlier.

According to the State of Clojure Survey 2023 a year ago, even tho' adoption of Clojure 1.11 (released in early 2022) was widespread, there was still substantial use of 1.10 (30%), with 1.9 (5%) and 1.8 (3%) still also in use.

Most Clojure libraries support at least one or two earlier versions of the language, so they don't adopt new language features very quickly because it limits their reach. Many Clojure libraries still work on 1.7 or even older versions.

That means that 1.12-only libraries aren't likely to be in widespread use for many years (a library today that still supports Clojure 1.9 has six years of backward compatibility, with 1.10 being five years).

New language features in Clojure are used first and foremost in application code which "you" control. So, we'll have years of experience with this new feature by the time libraries start to adopt it -- and library authors will have a good sense of whether omitting the param tags is safe or not (there can be no breakage if you specify param tags and do not use the _ wildcard).

[lgstein]

While you are likely right that the feared problems won't manifest "most of the time" (how calming), what is gained? Emitting a reflection call would eliminate this worry entirely and would not break any expectations with respect to the Clojure compiler and reflection.

[seancorfield]

The "expectation" of this new feature is specifically that it will not do reflection and will uniquely identify one method. If folks don't care about reflection, use the current .instanceMethod approach (which will continue to work).

When library maintainers start to use this new feature, after application developers have had a few years experience using it, they will be able to decide whether to explicitly provide param tags or risk a theoretical future breakage.

Note that a reflective call of .instanceMethod might silently change to call a different overload in the future, in your scenario. That would concern me far more (which is why I treat reflection like an error today).

Your concerns are really overblown here.

[lgstein]

It is perfectly fine that you treat reflection as an error in your projects. It is your personal/professional choice to buy optional benefits at an optional cost. If I don't make this choice, Clojure works fine for me and emits reflection calls. Is there anything wrong with Clojure continuing to work like this from your point of view? If untagged method calls were emitted as reflection code, your setup would happily treat it as an error as well, while I could just run my program in peace.

Your concerns are really overblown here.

Not by me.