commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Serializable (again)
Date Sun, 13 May 2012 16:16:33 GMT
> [...]
> > 
> > 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message