[
https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082643#comment-13082643
]
Gary D. Gregory edited comment on CODEC-125 at 8/10/11 8:13 PM:
----------------------------------------------------------------
I hope it does not matter unless the call site is typed to a {{StringEncoder}}
as opposed to an {{Encoder}}. You can only tell by looking at their code.
My issue with the current API is that the encoded values are themselves encoded
in undocumented format (the business with the {{"|"}}s). This feels unnatural
to me when the logical view of the data is clearly a set of encodings
(Set<String>).
It's just smelly to say that the return value is a String when in fact it is
not.
The other issue with not using a set is what happens if two inputs encode to
the same output but with elements in different order. For example, x -> {a,b}
and y -> {b,a}. With Strings the two results are not equal and with Sets they
are.
Tangent: My vision for the future of codec is that what is now a StringEncoder
would become a Encoder<String,String>. That cannot happen right away because
some encoders encode to multiple types, so it requires a little more thinking.
was (Author: garydgregory):
I hope it does not matter unless the call site is typed to a
{{StringEncoder}} as opposed to an {{Encoder}}. You can only tell by looking at
their code.
My issue with the current API is that the encoded values are themselves encoded
in undocumented format (the business with the {{"|"}}s). This feels unnatural
to me when the logical view of the data is clearly a set of encodings
(Set<String>).
It's just smelly to say that the return value is a String when in fact it is
not.
The other issue with not using a set is what happens if two inputs encode to
the same output but with elements in different order. For example, x -> {a,b}
and y -> {b,a}. With Strings the two results are not equal and with Sets they
are.
Tangent: My vision for the future of codec is that what is now a StringEncoder
would become a Encoder<String,String>. That cannot happen right away because
some encoders encode to multiple types, so it required a little more thinking.
> Implement a Beider-Morse phonetic matching codec
> ------------------------------------------------
>
> Key: CODEC-125
> URL: https://issues.apache.org/jira/browse/CODEC-125
> Project: Commons Codec
> Issue Type: New Feature
> Reporter: Matthew Pocock
> Priority: Minor
> Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff,
> bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch,
> bmpm.patch, bmpm.patch, comparator.patch, fightingMemoryChurn.patch,
> fightingMemoryChurn.patch, fixmeInvariant.patch, handleH.patch,
> majorFix.patch, performanceAndBugs.patch, testAllChars-mem-profile.html,
> testEncodeGna.patch
>
>
> I have implemented Beider Morse Phonetic Matching as a codec against the
> commons-codec svn trunk. I would like to contribute this to commons-codec.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
