is there something like the inverse of "->" out there? a macro that takes a nested lisp expression and a symbol and returns it in threaded form?

Hello! I'm taking a new job and going back to Rails land from Clojure world. I'm a little sad to leave functional programming, and would like to maintain some of the fp mindset, so if anyone knows any good resources/blogs that discuss what fp concepts work well for OO codebases and how best to apply them, I would greatly appreciate it 🙏

How do I access "this" inside toString ? And how to control the creation of the instance?

(.toString (proxy [PersistentArrayMap] []
             (toString []
               "42")))

that empty vector is the list of args to the superclass constructor

@souenzzo there's an implicit this you can access

user=> (str (proxy [Object] [] (toString [] (clojure.string/reverse (str (supers (class this)))))))
"}tcejbO.gnal.avaj yxorPI.gnal.erujolc{#"

there's also proxy-super for delegating to the superclass explicitly

user=> (str (proxy [Object] [] (toString [] (clojure.string/reverse (proxy-super toString)))))
"b94e08c1@a47291ff$tcejbO.gnal.avaj$yxorp.resu"

the this in proxy is the only "magic" anaphoric macro symbol in clojure I think

:>> in condp feels like a cousin of that

a little, but all keywords evaluate to themselves, so no issue there (vs symbols which evaluate to something else)

yeah - not the same thing, just a similar "magic" feeling

also marginal cases: catch, finally, inside try, and thrown? and thrown-with-message? inside clojure.test/is

in that they are not bound anywhere, but they have meaning implemented by a parent macro

I'm reading about core.spec and I came across one passage in the design rationale that I'm having trouble understanding. > Invariably, people will try to use a specification system to detail implementation decisions, but they do so to their detriment. The best and most useful specs (and interfaces) are related to purely information aspects. What's an example of "trying to use a specification system to detail implementation decisions?", as contrasted with a purely informational use of a spec?

spec'ing intermediate internal functions

or like some of the specs for clojure.core that people have written fall into this

they look at exactly what a function currently implements and spec that, which may eliminate things that will be supported in the future

clojure core functions are aggressively polymorphic and we continue to add cases over time - spec'ing that stuff is a form of unnecessarily reducing future options

That's what I thought it might be, but I was having trouble putting it into the right words. So I guess using spec for "implementation decisions" would be arbitrarily limiting what you can pass to or return from a function so that a given spec is always satisfied.

thanks!

so it seems like from the rest of that passage that spec is most useful at the edges of a program - informing and adding context to what other programs can send to or get from the program which uses spec.

certainly focused on the the functions that consume, transform, and emit maps of attributes