Sergey: I've been watching this exchange for a while. Daniel is absolutely correct. Sure, there are bugs and features not fully implemented in Oromatch, but this is most definitely NOT one of them.
If you don't understand Daniel's response, I suggest that you get the excellent O'Reilly book "Understanding Regular Expressions" and check your Perl man pages. Ultimately, Oro is designed to duplicate Perl 5's regular expression capabilities. And with the exception of a very few rarely-used features and problems with the case switch -- e.g., (?i), (?-i) -- I know of no serious bugs. We use Oro as the basis for regex recognition in our enterprise software. Test your suppositions in Perl before you assert an error in Oro. Good luck. Kevin Markey -----Original Message----- From: Sergey Samokhodkin [mailto:[EMAIL PROTECTED] Sent: Fri 5/6/2005 7:23 AM To: ORO Users List Subject: Re[4]: Pattern Regular Expressions: Consecutive ORs not handled corr ectl y Hello Daniel, Wednesday, May 4, 2005, 8:50:28 PM, you wrote: DFS> In message <[EMAIL PROTECTED]>, Sergey Samokhodkin writes: >>Not convinced yet. I still think there is a bug. >>Let's look at the javadoc: DFS> ... >>I cannot see where the perlre allows the "foo|foot" not to produce the >>exact match against "foot", which takes place in the case in question. DFS> I don't see how the javadoc can be any clearer about explaining the DFS> behavior. Run this test yourself and see: DFS> echo foot | perl -pi -e 's/foo|foot/bar/g' ....... ....... >>It obviously says about the partial rather than exact match, so >>it simply doesn't apply. DFS> I don't understand what you mean. Same for me. DFS> Perl expressions either match DFS> something or they don't matching something. They don't either DFS> exactly match the thing or partially match the thing. That's what I mean: $str =~ /^foo$/ - check for exact match, analog to matches() $str =~ /foo/ - check for partial match, analog to contains() DFS> foo|foot will never match foot in Perl, plain and simple. It DFS> will only ever match foo, as my substitution example showed. DFS> Awk is a different matter, because the longest possible match DFS> will always be found. You are referring, in essence, to the difference between the DFA- and NFA-based matchers. I don't see how it applies to our case. What I don't understand is, why the 'regexp("foo").matches(str)' is diffrent in behaviour from the 'regexp("^(?:foo)$").contains(str)'. IMHO these are the same and should behave the same. DFS> daniel DFS> --------------------------------------------------------------------- DFS> To unsubscribe, e-mail: [EMAIL PROTECTED] DFS> For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Sergey mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CONFIDENTIALITY NOTICE: This electronic mail transmission and any accompanying documents contain information belonging to Silver Creek Systems, Inc. that may be confidential and legally privileged. If you are not the intended recipient, any disclosure, copying, distribution or action taken in reliance on the information is strictly prohibited. If you have received the information in error, please contact the sender by reply email and destroy all copies of the original email. Thank You.
