Fork me on GitHub

If you end up printing the result of reify (because, say, you are misusing a value in the REPL), you get a fairly opaque #object[..] reference. It seems that you can implement toString in any reify call -- is that a reasonable option to provide a visible "hint" to the REPL user about what they did wrong?


(since Java objects were changed to print like that -- #object[..] -- I've seen quite a few people struggle to figure out what they might have done wrong if they end up with that in the REPL)


This came up again for me today because someone ran (next.jdbc/plan ...) in the REPL which produces an IReduceInit and they got

#object[next.jdbc.result_set$eval2218$fn$reify__2220 0x4fa3cd05 "next.jdbc.result_set$eval2218$fn$reify__2220@4fa3cd05"]
Which of course they did because it's a reify'd object 🙂 but the repeated string part in there is controlled by the toString implementation and can be changed into a hint about what might not have been done right...


As long as no one thinks it's insane to add toString to override that and produce a hint/error message, I'll probably go that way. Curious if there are any obvious downsides to that...


changing the reify to a deftype or defrecord would result in a friendlier class name


True. But these are dynamically constructed, from anonymous functions, and close over a bunch of stuff.


@alexmiller I'm stuck in a redirect loop when I try to login to atlassian, any ideas?


looks like fifteenth time was the charm

😂 4
Alex Miller (Clojure team)23:06:25

Sometimes there’s weirdness if the product access is wrong. I’m on phone but I’ll double check later