On 29/06/10 16:10, Sam Berlin wrote: > This sounds like a great idea. I think it'd be worth doing, with one > caveat: It's only worth it if *no more classes become public.* It's > already a shame that the internal package needs to expose some things as > public in order for other packages to use them, which leaks some > internal bits of Guice... a number of projects are already using the > internal classes, and I'd hate to expose even more of them.
Two classes (Classes and Stopwatch) need to become public. I agree this is suboptimal, but given Java lacks any kind of hierarchical or "friend" package access, it's inevitable that if you want to have a utility package, it will have to be public. I consider that having .internal. in a package name is a stern warning to any developer foolish enough to try depending on it. > If it's doable without these things becoming public, I think our best > bet is to try and solidify a 3.0 and *then* make the change, similar to > how 2.0 got pushed last time and then the internals were refactored. Could do, I guess, but I don't really agree that this makes sense. It makes most sense to do this in a major version number release. *This* release is already going to be one, but the next one might otherwise turn out to be 3.1. Unlike the post-2.0 refactor, the change I'm proposing is very simple, just renaming things with pretty much zero functional change, so should be quick to do, and safe. Having it happen before the release would ease the work of anyone who wants to backport fixes from trunk onto the current release. Max. > On Tue, Jun 29, 2010 at 3:54 AM, Max Bowsher <[email protected] > <mailto:[email protected]>> wrote: > > 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] > <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] > <mailto:google-guice-dev%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/google-guice-dev?hl=en. > > > -- > 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.
signature.asc
Description: OpenPGP digital signature
