Przemysaw Wojnowski writes:
> To reproduce eval this: (jde-import-find-and-import "set")
> This happens always when class in not already imported (eq to 'pass from
> verify function, which will be only called in interactive mode), so very
> 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.
Sorry to not get back to you faster, I've had a busy last few weeks.
I did get time to verify that there is that problem and I'll be
working on a fix.
> 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.
I understand and that approach works but as the project grows "many
simple things that do like things" start to become "many things that
do the same thing". There is a lot of redundancy in the project and
I'm trying to get rid of some of it.
The approach I'm trying is to make comprehensive functions that do one
specific thing well. One example is the jde-read-class and
jde-parse-class-name, which are two functions that should simplify
more code as we continue to refactor.
Yes, they are more complicated, but this is the tendency for where
things go when you add functionality. If you can simplify the code
without taking away any functionality, I'd be glad to have a look.
Also, please keep in mind that this was a pretty significant change to
the code base. This is code that's been sitting around for a while
and I had to make changes to retrofit them into the project as it is
now. We should expect these things to happen and is part of the
normal software development cycle.
> Another thing is that we need tests.
> At http://www.emacswiki.org/emacs/UnitTesting are described some testing
> libraries for emacs lisp. For java code we can use just JUnit or TestNG.
Yes, I agree.