@alexmiller: so this is a type hint problem http://dev.clojure.org/jira/browse/CLJ-1955 and dup of http://dev.clojure.org/jira/browse/CLJ-140

put it on the ticket

will do -- I have a dirty fix to VarExpr in the compiler, but a better fix is like bronsa says to remove the :tag typehints in core and adjust the arglists hints

if it's a type hint thing and all that's needed is to change the wrong ones I could do that (if no one wants to, that's it); if it's fancier I'd need a hint where to look at

@ghadi: it seems like generally it shouldn't be possible to break the ability to call .hashCode()

however, I'd say this is not at all high on my list of things to care about

it's not just hashcode tho 😃

go on...

or would hijacking the old ones in fn work better?

i meant defn

here's another example @alexmiller :

user=> (set! *warn-on-reflection* true)
true
user=> (.submit clojure.lang.Agent/soloExecutor str)
Reflection warning, elided.clj:1:1 - call to method submit on java.util.concurrent.ExecutorService can't be resolved (argument types: java.lang.String).
#object[java.util.concurrent.FutureTask 0x4b10966e "java.util.concurrent.FutureTask@4b10966e"]

that reflects because the compiler things str is a String and not a callable

actually it would reflect anyways because it doesn't know that a fn var deref is Callable -- but you see the gist of the type inference problem

I could probably think of a more problematic example.

like choosing the wrong method when java arguments are type overloaded

so the .hashcode thing is uninteresting except as a symptom. If you want to improve one of those tickets, maybe the older one is better, that's where I would start.

why did you say it would be better to adjust the :tag / typehints? seems like that's hiding the problem, unless you're saying that the code is actually wrong.

@alexmiller: yes that'd be indeed hiding the problem, but the problem is not solvable w/o breaking existing semantics

well then maybe we shouldn't solve it :)

mostly trolling :)

maybe we shouldn't 😃

people forget that's a defensible position

well, ret value type hints on a defn Var have been unofficialy deprecated for a while.. I wouldn't mind replacing all those instances in clojure.core with type hints on the argvec and printing a deprecation warning on old instances of type hints

I'd be fine with having a ticket like that (but without the patch on core as that is not worth maintaining) for Rich to look at

@dajjedzenie: sorry for ignoring you earlier, was trying to understand the problem

got it, np 🙂

Why have the var type hints been deprecated?

I’m still doing that to avoid having to use fully qualified type hints on the arg vec, although IIRC that might have been fixed in 1.8?