On Mon, Feb 9, 2009 at 9:27 AM, Reinier Zwitserloot <reini...@gmail.com> 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 <weiqi...@gmail.com> 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
>> weiqi...@gmail.comhttp://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/classes/com/sun/tools/javac/util/Pair.java
--
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 javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
