If you feel this strongly about it, feel free to submit it to project coin:
http://blogs.sun.com/darcy/entry/project_coin On Feb 9, 4:14 pm, Marcelo Morales <[email protected]> wrote: > On Mon, Feb 9, 2009 at 9:27 AM, Reinier Zwitserloot <[email protected]> > wrote: > > > Given that he customized this to being called 'Par', omitting the > > toString, and having the awkward Serializable requirement, it seems > > like it would be considerably LESS work in the long run to do it right > > once. It also seems obvious, given those mistakes, that he may have to > > make updates, so copy/pasting the class into every new project is also > > a bad idea, as then he couldn't easily make updates to this class. > > minor pains for such a small utility I'll say. Haven't need the > change, as flawed as it is. Didn't even look it a second time again > until I posted this. No work was ever required to maintain it. > > > > > Here are some more problems with your pair class: > > > 1. By using a constructor, you don't get type inference. Use a static > > method, like so: > > > public static <P, Q> Pair<P, Q> create(P a, P b) { > > return new Pair<P, Q>(a, b); > > } > > > and then make the actual constructor private. > > > 2. While you're at it, you can also fix your serializable issue, by > > making two constructors: > > > public static <P extends Serializable, Q extends Serializable> Pair<P, > > Q> create(P a, P b) { > > return new Pair<P, Q>(a, b); > > } > > > public static <P, Q> Pair<P, Q> createNonSerializable(P a, P b) { > > return new Pair<P, Q>(a, b); > > } > > Understood and agreed. > > > > > > > so, now by default things have to be serializable, but you can get > > around the issue if you want without having to bother with raw types > > and @SuppressWarnings("unchecked"). > > > (If you're really anal about it, you can create a Pair class and a > > SerializablePair subclass, and have the create() method return a > > SerializablePair, but I'd have to question your sanity). > > > Also, your insistence on Serializable is itself a code smell; because, > > as Keith Haber suggested: If serializable 'seems like a good idea', > > then so does Comparable, and then why not Runnable (for if both pairs > > are Runnables and you want to run both of them, or some such). Where > > do you draw the line? Sure, serializable needs special treatment > > because its such a bad design, but that's actually a good reason to > > work around it as best you can. > > You talk as if implementing serializable was a whim. It was not. Don't > take it so seriously ;) > > > > > NB: Here's something I might submit to Project Coin: Make all entities > > serializable regardless of whether or not they implement Serializable, > > but run every attempt to serialize a non-serializable through the > > securitymanager. > > > On Feb 9, 3:08 am, Weiqi Gao <[email protected]> wrote: > >> Reinier Zwitserloot wrote: > > >> > If you've been adding it to every project, why not make a jar out of > >> > it? > > >> Because that would be more work than writing the class. > > >> -- > >> Weiqi Gao > >> [email protected]http://www.weiqigao.com/blog/ > > Just for fun, I googled Pair.java. There are HUNDREDS of them. Even in > the official distribution, the compiler contains > one:http://www.google.com/codesearch/p?hl=en#zBm1I2MD8bU/src/share/classe... > > -- > Marcelo Morales --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
