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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home:
www.michaelneale.net
blog:
michaelneale.blogspot.com