I think you should clean room implement it (or reuse some old code of yours if it is safe to do so). From what I have seen of the algorithm - it isn't huge - and it would make sense to have it re-implemented. As an alternative - consider taking a look at the MVEL soundex code and rewriting that - and we will see if we can make it upstream. I would say it is just slightly neglected - its not well known that it lives there. Using the MVEL one was just opportunistic for drools.
I didn't know that it could return null, that is bad. I guess if it is null - that would mean that you just do a literal case insensitive compare?
Also - AFAIK - soundex is only for english right? Is there an equivalent for other languages? If so, perhaps having it in the drools codebase makes sense and opens the way for people to plug in their own soundex.
On Mon, Oct 11, 2010 at 2:54 AM, Wolfgang Laun
<wolfgang.laun@gmail.com> wrote:
The implementation of "soundslilke" is broken in more than one respect. The conversion of a word to a Soundex string is provided by org.mvel2.util.Soundex.
(.) There are words where Soundex.soundex returns null, so that the calling code, in Drools, crashes with a NPE.
(.) The algorithm implemented in Soundex is erroneous. I'm not sure which Soundex algorithm it is supposed to implement, but it just doesn't meet the basic requirements.
I have implemented, correctly, the version for the National Archives and Records Administration (NARA) rule set for the official implementation of Soundex used by the U.S. Government.
Do we wait for MVEL to correct this bug, or do we just replace it with a correct implementation?
Regards
Wolfgang
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home:
www.michaelneale.netblog:
michaelneale.blogspot.com