Sorry I've taken so long to respond. I wanted to take a little extra
time to look at the code both to confirm and work out a fix, but also
to address you more broad concern about the complexity of the code.
To first address the latter, I do agree some of the functions are more
complicated and in general, that does make things harder to maintain.
I do think there is a trade off for robustness, however. I think with
the simplicity of many of the functions in JDEE there is not enough
robustness and too much redundancy.
I think it's hard to have both of these at the same time and I would
agree that a three page long function should be broken up in to
several others but there are, albeit few, reasons for not even doing
that given the nature of emacs lisp.
Take `completing-read' for example, which is a function which takes
eight arguments. At one point, I wrote another facade like function
that delegated to this function to handle the most common way I used
the function. But what I found is that adding another method created
another function I have to include in other source code (JDEE
included) and one more moving part to maintain. For all of these
reasons, I went back to just using `completing-read'.
In JDEE, we have a lot of different code to look up classes and fully
qualify them and this was yet another function that did that. It
makes sense to me to reuse one centralized function (`jde-read-class')
to qualify interactively, which was this change. The "correct" fix
would be to move the code that takes an unqualified class name into a
non-interactive function and use it in the parsing code you mentioned
This is a more significant change I'll get to later (unless someone
else beats me to it) so for now I've reverted this function to using
`jde-read-class' but also leaving the other part that allows it to
On Sep 28, 2009, at 5:15 PM, Przemysław Wojnowski wrote:
> To reproduce eval this: (jde-import-find-and-import "set")
> This happens always when class in not already imported (eq to 'pass
> verify function, which will be only called in interactive mode), so
> Example scenario is when jde-complete calls jde-parse-eval-type-of,
> which subsequently calls jde-parse-get-qualified-name with import
> argument set to true, which calls jde-import-find-and-import.
> Quick fix is to revert to previous version of the function.
> IMHO many of JDE functions are too long and are trying to do too many
> different things (e.g. parse args, validate, resolve sth, etc.). For
> this reason they are hard to understand, test and debug.
> Another thing is that we need tests.
> At http://www.emacswiki.org/emacs/UnitTesting are described some
> libraries for emacs lisp. For java code we can use just JUnit or
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> developing skills, take BlackBerry mobile applications to market and
> ahead of the curve. Join us from November 9-12, 2009. Register
> jdee-devel mailing list