I apologize for diving into a solution in my first email -- let me give a
little more of the background as to what I am trying to accomplish.
I'm proposing an additional syntax for Java interop for the purpose of allowing
support for more precise code-completion of Java fields and methods in Clojure
tooling. The new syntax proposal is why I'm emailing this list rather than
directly going to the project owners of the projects I've modified to support
this. If there is high resistance to any additional syntax for Java interop,
there's not much reason to try to convince the project owners of cider-nrepl
and compliment to support something just for my personal use :-).
Note also that when I say "propose additional syntax" I do not mean "please add
this to clojure lang" -- I've implemented this as a couple of macros which
should be the way the language normally gets extended. I just want feedback
and am trying to gauge interest, because if no one wants this then it's not
worth any of the additional effort to "publish" it -- I'll just manage it as a
utility library for myself.
So when I say more precise code completion for Java fields and methods, I mean
this:
- I want my development environment or REPL to know the type of the Java
object I'm operating on so it can limit the completion list to fields or
methods that are valid for that particular type.
- For example, when typing:
(.get
I'd somehow like my environment to know that I want code completion for a
Java object of type "this.is.AType"
and as such, I would only see methods or fields starting with ".get" for
that type
What happens for me now, is I see some Java methods and fields starting
with ".get" but on a number of Java objects (and not a complete list at that).
(I believe the tooling looks through symbols in your namespace, finds
Java symbols, and starts pulling methods and fields from any of them). Using
only the text "(.get" the environment cannot know what I'm trying to do.
Now the tooling could do static code analysis, it could look at the
surrounding top-level form, and say, what are the locals, are they type-hinted,
and only show me Java methods and fields from locals that have type hints.
Even this approach though, which is complex and error prone to implement, still
doesn't limit my list to just methods and fields of "this.is.AType" unless I
only have one type-hinted local symbol.
So... if we had a syntax that looked like:
(Type:method obj? args)
My tooling becomes drastically simpler. Now my tooling is fed:
"Type:method"
And code completion simply becomes:
- Look up Type in my active namespace symbols (to find out if it's a Java
type I've imported) (or it could simply be fully qualified, both are supported)
- Use reflection to find a list of candidate fields and methods
No static analysis required, simple to implement.
It's so simple to implement that I hastily pasted in my
proof-of-concept/prototype code in the first message -- which hopefully is easy
for folks to just try. I hope that people will try it and think: this would be
great if I were writing a lot of Java interop code -- or better yet, give
suggestions on how to improve it.
So try this by:
1) Install boot (or update it via "boot -u")
2) Make a new temp directory and navigate to it
3) Run the first command from my prior email in bash
4) Paste in the code snippet to the resulting rebel-readline repl
5) Try the limited completion right in rebel-readline
6) Connect using your cider-nrepl based tooling (CIDER, inf-clojure,
vim-fireplace, others?), and try it from one of those tools. I've only tested
with CIDER -- in my CIDER I get eldoc, help at symbol at point (I wish this
displayed javadoc inline), and better code completion.
7) Feedback! :-)
I also realize that this stuff is complex enough that there might be some set
of CIDER settings that solve this problem that I just simply don't know about
or didn't find. Love to hear about how others get better Java interop code
completion. Some of my clojure projects involve lots of Java interop and this
would have been sooooo nice to have while writing those projects (in my
opinion).
I think there are other advantages to this style syntax (besides supporting
code completion):
- Right now I have the jvm macro throw an error if it can't find the java
symbol -- so you would get a compile time error rather than just a reflection
warning about a non-existent java method.
- In addition to making easier to *write* Java interop, I think it makes it
easier to *read* Java interop
I immediately know the Java type while reading the code, no need to hunt
down the type annotations elsewhere. I've been writing Java since Java 1.1 and
I still like the reminder of what class a method is from.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 16, 2018 4:23 PM, Timothy Baldridge <tbaldri...@gmail.com>
wrote:
> I don't understand why this is needed. Why can't cider code complete on the
> normal method format? What's the problem this code is trying to solve?
>
> Timothy
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
