On 17 August 2011 13:58, Stephen Colebourne <scolebou...@joda.org> wrote: > On 17 August 2011 13:44, Matthew Pocock <turingatemyhams...@gmail.com> wrote: >> It seems to me that the Encoder/Decoder interfaces are screaming out to be >> generified, and the current sub-interfaces should be removed unless there's >> a compelling reason for them e.g. if they add extra methods. It is no >> hardship in your code to write Encoder<String, String> rather than >> StringEncoder. I realise that in any one application it may be the case that >> they use only one family of encoders (e.g. String => String), but I don't >> see why this means we should be introducing a Java interface explicitly for >> this use case. > > I prefer StringEncoder to Encoder<String, String>. Its shorter and clearer. > Overall, I'd say focus users on the concrete versions like StringEncoder.
If StringEncoder is a non-generic interface it also makes it possible to combine interfaces in classes, as is done currently. Not sure this is possible with all-generic interfaces. > On 16 August 2011 21:38, Gary Gregory <garydgreg...@gmail.com> wrote: >> I am not a fan of these interfaces because they are not typed, "Object >> encode(Object)" is too vague now that Generics have been an option for >> years. > > The Object encode(Object) approach is still valid if the primary use > case of the interface is for frameworks. In a framework, objects are > generally treated as of type Object, so the API is fine. User code That's useful to know (I've not used frameworks) > should use concrete versions. +1 > Stephen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
