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. 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 should use concrete versions. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
