On 5/24/07, <b class="gmail_sendername">Scott Reed</b> <<a href="mailto:sreed@spamcop.net">sreed@spamcop.net</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Unless I never looked at the name except in the source code, I don't see the much point in having<br>two names that can be distinguished (due to hashcode inclusion) but have been semantically<br>disconnected from the source code rules. If an error occurs in one of those rules, how will you know
<br>which one the message refers to? How will you make sense out of the log? It makes more sense to me<br>to replace non-alphanumeric characters with alphanumerics as Ron's team member proposed.</blockquote><div><br>Yeah, it's true that including a hashcode allows you to go from the "real" name to a unique generated one, but doesn't really help you go back the other way, unless you ALSO store the original name as a string in the rule, where you can use it to refer to the rule by name in exceptions and so forth.
<br></div><br>An alpha replacement could be difficult given the number of potential non-alpha characters.<br><br>The other option, probably more work, would simply be to improve the validation and error reporting such that it was clear which two special-characters-included rules conflicted, and why they conflict.
<br><br>e.g. "RNR Qty == RNR Adjustment Qty : 100% Tolerance" has the same translated rules name as "RNR Qty >= RNR Adjustment Qty : 100% Tolerance"; please rename one of these rules.<br><br>That'd make the problem a little more clear, but I don't like it as much.
<br><br>Anyway -- I'm not writing the code, so I'll just let Edson et. al figure it out. :)<br><br> - Geoffrey<br></div>-- <br>Geoffrey Wiseman<br>