I sent this a month ago and no one commented :-/ Resending... On 22/04/10 11:11, Max Bowsher wrote: > I've recently been attempting to understand how Guice works. My initial > impression on looking at com.google.inject.internal is "Wow, what a lot > of classes, this is quite daunting!". > > On further inspection, it turns out that about a third are general > utility common code. I would like to propose that such classes move to > com.google.inject.internal.util (or similar) to render the package > containing the core internal logic of Guice less crowded. > > My initial list of candidates to move is: > > AbstractIterator.java > AbstractMapEntry.java > AsynchronousComputationException.java > Classes.java > Collections2.java > ComputationException.java > CustomConcurrentHashMap.java > ExpirationTimer.java > FinalizablePhantomReference.java > FinalizableReference.java > FinalizableReferenceQueue.java > FinalizableSoftReference.java > FinalizableWeakReference.java > Finalizer.java > Function.java > Hashing.java > ImmutableCollection.java > ImmutableEntry.java > ImmutableList.java > ImmutableMap.java > ImmutableSet.java > Iterables.java > Iterators.java > Join.java > LineNumbers.java > Lists.java > MapMaker.java > Maps.java > NullOutputException.java > ObjectArrays.java > Objects.java > Preconditions.java > Sets.java > SourceProvider.java > StackTraceElements.java > Stopwatch.java > Strings.java > ToStringBuilder.java > UnmodifiableIterator.java > > The vast majority of these can be moved with nothing more than package > and import statement changes. The exceptions are: > > * Classes and Stopwatch would have to change from package-private to > public - I'd classify that as an acceptable compromize for more readable > code, given that all of the others mentioned above are already public > anyway. > > * Finalizer and FinalizableReferenceQueue have string literal and > javadoc references to classnames that need fixing up. > > > You would expect that there would be no dependencies from the utility > package to the rest of Guice. With the above moves, this is nearly the > case: the exception is that StackTraceElements and LineNumbers refer to > some methods in MoreTypes. Proper separation could be attained by > separating MoreTypes into the parts that deal with Guice TypeLiterals > and the parts which deal with pure JDK classes. > > > Please let me know what you think of this idea, so that I know whether > it's worth me working up an actual patch. > > > Max. > >
signature.asc
Description: OpenPGP digital signature
