any plans in making this true?

(instance? java.util.function.Function (fn []))

would help a lot with the Java interop.

We looked at it some for 1.10 and will probably take another swing at it in 1.11

I can’t search right now but there is a jira for it

found, https://clojure.atlassian.net/browse/CLJ-2365

that's the one, Ghadi's been working on it off and on

@ikitommi one thing we're thinking about is whether we can add the proper SAM interface to IFn automatically based on context. Not just for j.u.f.Function

@ghadi Do you mean doing SAM conversion for IFns? I would love that.

it would be really cool but it's tricky

I have no doubt.

But 💯 from me.

the goal would be to not have to specify SAM classnames or the SAM name itself

I guess it’s tricky because of overload resolution?

(.setUncaughtExceptionHandler (Thread/currentThread) (fn [t e] ....))

if we could make that work ^

the argument to setUncaughtExceptionHandler is a Thread$UncaughtExceptionHandler, which is a SAM

How is that different from full SAM conversion?

would be cool to auto-attach that interface to the fn

Yes, it absolutely would.

so would only work if the fn is inline?

yeah

no way to generically do that through vars

So you wouldn’t create wrapper interfaces in other cases?

could you do it with a defn if the user annotates it?

there are a lot of different things to explore here 🙂

you could dynamically spin adapters too, with indy

(.setUncaughtExceptionHandler (Thread/currentThread) (fn [t e] ....)) for that to execute without a ClassCastException, the third argument must be a Thread$UncaughtExceptionHandler,

whether it is an IFn too doesn't matter

my challenge is: can you do it without having to name that class?

(which would mean you need to propagate the calling context of setUncaughtExceptionHandler into the analysis of the fn)

or dynamically adapt fn with invokedynamic

Surely you wouldn’t need to do that if you just created a wrapper class at the invocation point?

that == which?

the extra calling context analysis?

(reify Thread$UncaughtExceptionHandler (uncaughtException [t e] (my-fn t e))

i.e. you wouldn’t need to extend the analysis of IFn

how do you know when to adapt vs. not?

again only with literals, maybe?

if someone provides a Thread$UncaughtExceptionHandler

Always adapt

meh

wrappers suck

And let hotspot deal with it.

you can write wrappers in userspace at your delight

The problem is I don’t delight in doing it.

not a wrapper but some helpers ^

with a wrapper, who looks up the proper classname @cfleming?

How do you mean?

Ugh, I really have to run, sorry, but I’m very interested in this.

what triggers the emission of (reify Thread$UncaughtExceptionHandler (uncaughtException [t e] (my-fn t e))?

np

Right, the problem in a dynamic lang is knowing what you have, I guess.

just wanted to say that extending IFn to j.u.function.Function is only 1% of the problem

which was suggested earlier

if it was easy, it would already be done :)

there probably exist 0 use cases of things that need the functional interface && IFn

when you want to interop with the functional interface, you no longer care about IFn