RE: Re[4]: Pattern Regular Expressions: Consecutive ORs not handled corr ectl y

------_=_NextPart_001_01C55252.AD9C7EBC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[Resending -- MS Exchange malformatted one return address.  Apologies =
for any duplication.]

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. =20

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
=20
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 =3D~ /^foo$/  - check for exact match, analog to matches()
$str =3D~ /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]



--=20
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.


------_=_NextPart_001_01C55252.AD9C7EBC--