As you say, this is a limitation in the code completer. In Cursive this problem doesn't exist to this extent, when I type `(.get` the completer responds with a list of methods and classes that could be completed to that method, starting with classes in the namespace I'm currently editing.
Yes, this takes static analysis, or perhaps some indexing and introspection. But changing the syntax is never really going to gain traction here, as manually typing the name of every method just so my editor can produce a list seems like me conforming to my tool rather than my tool learning to work with me. The imported classes in the current namespace are stored in the mappings attribute. It seems like an editor should be able to install hooks into that and index the methods on the classes to provide this feedback. https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Namespace.java#L123 On Tue, Oct 16, 2018 at 1:26 PM 'somewhat-functional-programmer' via Clojure <clojure@googlegroups.com> wrote: > 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
