search

jonase / eastwood

Clojure lint tool
1.09k stars 66 forks source link

Weird exception with namespaces in extend-protocol #456

Closed aldebogdanov closed 1 month ago

aldebogdanov commented 1 month ago

I have try to use eastwood 1.4.3 plugin in my project, but encountered weird behaviour. It throws an exception in code where I am extending protocol for record from another namespace. Like this:

(ns example.impl
  (:require [example.api.buttons :as b]))

(extend-protocol b/KeyboardButton

  b/TextButton
  (transform [this user] ....

On the line with b/TextButton Eastwood throws:

Got exception with extra ex-data:
    msg='No such var: b'
    (keys dat)=(:form :file :end-column :column :line :end-line)
    (:form dat)=
^{:line 32} b/TextButton

ExceptionInfo No such var: b

If I try to use fully qualified namespace it throws the same.

vemv commented 1 month ago

Hi!

Thanks for using Eastwood.

Out of curiosity, did you try using the fully qualified example.api.buttons.TextButton name?

It wouldn't surprise me if tools.analyzer was being more strict than the Clojure compiler by expecting a class name (those aren't alias-eable), not a symbol name.

aldebogdanov commented 1 month ago

Oh yes! Thank you. I tried now fully qualified class name and it was OK.

But it anyway looks weird that to achieve clean linter output we need use such uncommon notation

vemv commented 1 month ago

It's not that odd considering that extend-protocol works over one protocol (which is a var among other things) and N classes (which aren't vars).

One cannot refer to e.g. java.util.Date using ju/Date notation so the fact that Clojure allows b/TextButton might be one of those historical oddities (such as https://clojure.org/guides/faq#unreadable_keywords)

Anyway, Eastwood is heavily based off the mentioned tools.analyzed library, and changing how strict it is, is beyond our scope.

Cheers - V