Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Macro invocation is treated as 'Unneeded anonymous function' #50

Open
joelittlejohn opened this issue Sep 10, 2012 · 4 comments
Open

Macro invocation is treated as 'Unneeded anonymous function' #50

joelittlejohn opened this issue Sep 10, 2012 · 4 comments

Comments

@joelittlejohn
Copy link

I see this output from kibit:

[null] Consider:
  warn
instead of:
  #(warn %)

However taking kibit's advice results in the following compile error:

Can't take value of a macro: #'clojure.tools.logging/warn

I guess the unneeded functions section of misc.clj needs to understand the difference between a function invocation and a macro invocation.

@joelittlejohn
Copy link
Author

Another problem (similar) is that Java constructs are considered to be first-class functions, which they are not. So kibit currently recommends this:

[null] Consider:
  Boolean.
instead of:
  #(Boolean. %)

But this is not correct, because Boolean. is not a function. It must be wrapped in a lambda to be passed around as a function. Similarly java interop calls like .toString are also not functions. So the following examples don't work:

(apply .toString [123])

(map Boolean. ["true" "false"])

but these do work:

(apply #(.toString %) [123])

(map #(Boolean. %) ["true" "false"])

@danielcompton
Copy link
Member

This is a fundamental limitation of kibit. I don't think there's a way to work around this but I'd be happy to hear ideas.

@joelittlejohn
Copy link
Author

@danielcompton, I don't currently follow how the lack of macro expansion (that I think you're referencing from the readme) means that this cannot be solved. Would it not be possible to e.g. change the rule so that any function name that begins or ends with . is not considered eligible for this rule?

Sorry if I've missed what you're getting at here.

Cheers

@danielcompton danielcompton reopened this Nov 11, 2014
@danielcompton
Copy link
Member

Gotcha. We can't cover the general case of all macros but it should be possible to exclude sugared Java interop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants