Fork me on GitHub
#clojure-dev
<
2019-06-11
>
seancorfield22:06:23

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?

seancorfield22:06:09

(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)

seancorfield22:06:30

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...

seancorfield22:06:42

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...

hiredman22:06:06

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

seancorfield22:06:09

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

bronsa23:06:06

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

bronsa23:06:22

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