I like the enum idea too. G
On Wed, Oct 3, 2012 at 2:12 PM, Duncan Jones <dun...@wortharead.com> wrote: > On 3 October 2012 18:24, Jörg Schaible <joerg.schai...@gmx.de> 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 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
