Re: Dealing with Repository class.

Hi,

> First, the problem I ran into.  There are several
> instances in the BCEL code (and in the Quilt code)
> which refers to static methods on the Repository
> for finding information about a class:
>    getSuperClasses
>    getInterfaces
>    instanceOf
>    implementationOf
> 
> These methods all use the system classpath.  (Whereas
> the ClassLoader I was developing used the 
> AntClassLoader.)
> 
> What I would like to do, is two fold:
>   Part 1 - Move those four methods onto the JavaClass
>   object.  In most circumstances, at least one 
>   JavaClass is available, and can be used for the
>   query.

That would be nice in that it would be more "object-oriented", however,
the information needs to be gathered somewhere ...

>   Part 2 - Remove the staticness of the Repository
>   class, such that more than one Repository can exist.
>   This will enable two BCEL programs to operate in
>   the same JVM, which could be helpful as BCEL tasks
>   end up in Ant scripts.

That would be OK, but I think that a lot of code is relying on the
"old" repository. I'd rather make it deprecated and replicate its
code in a subclassable new repository.

Cheers
	Markus