On Thursday 26 September 2002 02:35 pm, Daniel F. Savarese wrote: > Steve Downey wrote: > >The odds of having two projects that require regexp packages that can also > >tolerate having the definition of regular expression changed underneath > > them approaches zero. > > I agree with this as far as most applications are concerned. I don't > know the original motivation for this thread, but I can offer the reasons > why it's thought to be useful in jakarta-oro. The original motivation was a proposal to have a commons-regexp package like commons-logging that would abstract out the differences between different regexp packages. IOW, to be able to plug either jakarta-regexp or jakarta-oro in as implementation where a regexp is required.
Actually the original motivation was the suggestion that HttpClient's parser use regular expressions to match parts of the HTTP spec, rather than write the parser by hand. The spec provides BNF, and converting that to regular expressions is fairly straightforward. Since the regular expressions would have to be defined and understood by HttpClient, changing the implementation of the regular expression parser would probably cause bugs. Either the regexp would be illegal, or return different results. Also, one of the motivations for commons-logging was that logging needs to interoperate. Two logging packages for an application is a disaster. Two regexp packages for an application is an inconvienence. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
