On 29/06/10 01:27, Sam Berlin wrote:
I believe that Guice SVN is ready as-is for a 3.0 release, but if you are all able to glance at any open issues and point out major ones that can be solved, it would be appreciated.
I made a suggestion on this mailing list some time ago entitled "Move internal utility code to separate package?" to which the response was somewhat lukewarm, and included some measure of "not until a major release".
Given that you're now heading into a major release, I'd really like someone to give me the answer I'm looking for, namely either "Yes, it's worth you working up a patch for this" or "No, we're not doing it."
Max. =========== Original email copied below =========== 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. -- You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
