> [...]
> >
> > Hmm, a "PointValuePair" is not a "Pair"... That's an original view. :-)
^^^^^^^
>
> I am not sure whether this was an attempt at humor or not.
See ^^^^.
>
> My point is not that PointValuePair is not a pair (without uppercase).
> My point is that the base Pair class does not bring anything here. This
> base class provides getKey, getValue methods, equals and hashcode
> methods. The notion of pair has nothing to do with keys, but I think
> this came from the original Map.Entry this class did implement long ago.
> It also has nothing to do with values, but in this case this term fits
> well. So of the four methods provided by Pair, two are unneeded, one
> simple accessor is badly named, and the other accessor is good but this
> seems to be by accident. So Pair as a base class serves no purposes
> here. Setting PointValuePair a subclass of Pair only because of the name
> or the fact it has two attributes is stretching inheritance too far.
No, the real problem (not a serious one) is that indeed the "Pair" class
was mimicking "Map.Entry". Maybe that we should have chosen "getLeft()" and
"getRight()" instead of "getKey()" and "getValue()", respectively. [With
their own "problems": There's been a discussion about another Commons
component's implementation of the pair concept with pros and cons of the
various naming variants.]
The main point is that a "PointValuePair" _is_ a "Pair"! Nothing is more
obvious to me.
>
> In this case, it also complicates other things (here serialization).
> As there is a solution for this (provided by Jörg and yourself), I will
> use this and let this inheritance as is. I am not happy with this
> complex solution which seems to me over-enginneering, but I will use it.
Complex, I agree, but the cleanest solution to the "non-problem" of
providing serialization where we shouldn't. "Serializable" was not a good
Java feature, that's the real problem.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
