Fork me on GitHub
#clojure-dev
<
2018-11-02
>
alexmiller20:11:00

it’s a little subtle to see just from a commit, but Rich dropped a really nifty feature today - implement protocols per instance via metadata

metal 1
favila20:11:06

is specify and specify! next? is this a rare case of a cljs feature going back to clj?

alexmiller20:11:20

I don’t think so :)

dpsutton20:11:32

in time for 1.10 or next cycle?

alexmiller20:11:38

it’s in master now

👍 2
bronsa20:11:01

isn't that going to slow down dispatch quite a bit?

alexmiller20:11:27

just adds a check for meta in the existing path

alexmiller20:11:37

it will completely break your satisfies? patch though :)

alexmiller20:11:46

user=> (defprotocol P (report [x]))
P
user=> (report (with-meta [1 2 3] {`report (constantly "yo")}))
"yo"

bronsa20:11:04

I couldn't remember which ticket this code path reminded me of, satisfies was the one :)

bronsa20:11:10

yeah this is cool

alexmiller20:11:13

direct impls still checked first so those should be unchanged

bronsa21:11:55

uh, that seems a bit weird to me

bronsa21:11:16

user=> (defprotocol P (f [_]))
P
user=> (defrecord T [] P (f [_] 1))
user.T
user=> (defrecord Y [])
user.Y
user=> (f (T.))
1
user=> (f (with-meta (T.) {`f (fn [_] 2)}))
1
user=> (f (with-meta (Y.) {`f (fn [_] 2)}))
2
user=> (extend-type Y P (f [_] 3))
nil
user=> (f (Y.))
3
user=> (f (with-meta (Y.) {`f (fn [_] 2)}))
2

bronsa21:11:30

the difference is a bit surprising to me

bronsa21:11:15

I guess it's a compromise for performance?

bronsa21:11:03

makes sense

alexmiller21:11:08

well, not compromise as much as - direct impl should always win for perf

alexmiller21:11:12

so more goal than compromise

alexmiller21:11:34

also, you might notice that symbol can now take a var or a keyword … and tehre was much rejoicing

alexmiller21:11:47

user=> (symbol #'+)
clojure.core/+

alexmiller21:11:15

I added the guts in var during my error work as a half-way point and Rich picked it up here :)

bronsa21:11:51

no more need for .sym!

alexmiller21:11:53

I thought you in particular would enjoy this :)

👍 1
seancorfield21:11:15

Nice! I can simplify some (symbol (name x)) calls since symbol accepts a keyword now 🙂

slipset22:11:05

Tinkering about spec’ing stuff in clojure.set and the perennial question comes about: Would one accept a patch for the functions in clojure.set that coerces args to be set? The reason I’m bringing this up now is that AFAIU, the reason for not doing this previously is that the coercion has been considered expensive. but with https://dev.clojure.org/jira/browse/CLJ-2362 set should be a basically a noop if the arg is a set?

slipset22:11:20

A simple no is a great answer 🙂

alexmiller22:11:02

don’t know. certainly code exists that does not meet that and I would be loathe to break it.

slipset22:11:32

Hmm, my suggestion is to patch the functions in clojure.set so they start out by calling set on their args.

alexmiller22:11:50

well, that would break existing code

alexmiller22:11:11

sorry, not thinking straight

alexmiller22:11:24

you’re talking coercion not checking so I guess that would potentially be ok

seancorfield22:11:14

Coercing arguments to sets would ensure those functions always returned sets -- but there may well be code out there depending on getting non-sets back perhaps? (and, yes, you could easily argue such code is "broken" already)

simple_smile 1
alexmiller23:11:03

I’d argue expecting non-sets back is broken

seancorfield23:11:18

I wonder how much code out there is "broken" on those grounds? 🙂