I had previously shared these thoughts about more sophisticated autocomplete.
However, it looks like even those ideas don’t perfectly cover the use case I currently have in mind!
At the moment, I’m working with a Julia package that somebody else has developed. It’s a homebrew Julia implementation of a decent-sized API that has been professionally developed for other languages (C#, Java, Python). I had considered either using the
jcall library, or writing such an API myself, until I found this package; the package has over 3,000 lines so I’d really like to leverage what has already been done.
Even though it’s homebrew, it’s surprisingly well-maintained. However, like anything homebrew, it’s poorly documented. The author trusts that you will be familiar with the existing API. Unfortunately, I am not.
That said, the author appreciates Julia’s functional style, so some things are slightly different from the official API. For example, the member methods provided by the official API’s
EClient object are instead globally-accessible methods specializing on a
::Connection object. Some of these methods retain their original camelCase, while some became snake_case.
All this means that, to use it, I must refer to the official API documentation (in a different language), while acknowledging that some things will be different, and while having no method discoverability in my IDE. One must be a diehard [and irrational] Julia enthusiast not to jump ship for Python.
So would an autocomplete work with it?
Using the ideas I proposed above, mostly yes. The methods that had previously been members of
EClient in the official API are now specialized to take a
::Connection object as their first argument in the Julia package, so those should be discoverable.
However, quite a few functions have been written without type specialization, presumably in part because the package author didn’t
export them and can rely on module encapsulation. These will prove more difficult. And as this is not the sort of library that will have a large presence of users on GitHub, there won’t be good data to draw from for statistical inference.
Is there a way to improve that?
I think there’s a way to solve that problem too, even if imperfectly. When you have an object of type
MyType which has been defined in package
MyPackage, it’s fairly likely that at least some methods that have been defined in
MyPackage will have been written to operate on
MyType objects (even if the package author hasn’t given them type annotations).
As a result, when searching for methods, it seems a fairly sensible starting point to look first in the package where the type you are working with was defined. It could be an option in the autocomplete whether to include non-exported methods or not.
My IDE is [usually] able to bring me to the line of code where a particular function or type is defined, so this seems doable.
In short, it seems that once you tell your IDE what objects you’re working with, and you’ve communicated to it that you’re about to call a function on them, it should be able to help you find methods, searching through some combination of:
- Type specialization
- Statistical inference
- Package co-location / code proximity