[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13469207#comment-13469207
]
Mirko Raner commented on CODEC-158:
-----------------------------------
Correct, binary compatibility will not be affected.
Regarding the duplicate BinaryCodec class, here are some alternative names
(sorted according to my own preferences, most preferred one first):
- BinCodec (consistent with Codec suffix but breaks naming scheme related to
its encoder/decoder)
- BinaryEncoderDecoder (breaks Codec suffix scheme, but consistent with regards
to the prefix)
- CommonBinaryCodec
- IBinaryCodec (uses 'I' prefix for interface, which is not really used by
Apache Commons)
I'm open to any other suggestions as well.
The two additional alternatives that come to mind are (1) rename
org.apache.commons.codec.binary.BinaryCodec (a breaking API change; probably
not a good idea), and (2) remove the BinaryCodec interface without a
replacement (essentially trading in functionality for clarity).
Please let me know in which way I should fix this problem and I will submit an
updated patch.
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---------------------------------------------------------------------------------------
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
> Affects Versions: 1.7
> Reporter: Mirko Raner
> Priority: Minor
> Attachments: CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
