I like the enum idea too. G
On Wed, Oct 3, 2012 at 2:12 PM, Duncan Jones <[email protected]> wrote: > On 3 October 2012 18:24, Jörg Schaible <[email protected]> wrote: > > Matt Benson wrote: > > > >> Urgh; I find these method names rather painful. Why wouldn't we > >> simply provide endianness and bit ordering as enums, and parameterize > >> accordingly? > > > > Because the algorithm is different (although similar) every time and not > all > > combinations are implemented? > > > > Honestly, we would have to use in most cases a switch/case statement > > internally anyway and either throw UnsupportedOperationException for the > > unimplemented cases or someone would have to implement it ... ;-) > > I think the enum-based solution is much more elegant; the JavaDoc > could then contain a table demonstrating which combinations are > supported. The better of two evils, IMO. > > I'm always in favour of methods that can be easily understood from a > cursory glance. It bodes well for easy code maintenance. > > Duncan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
