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. Having a generic API for regular expressions allows you to write text processing classes, for example tokenizers, whose use depends on user-defined regular expressions. The developer using the library can then choose a regular expression grammar that meets his particular needs or fancy. I view it more as a library-building convenience. But there are some instances where an application would make direct use of the facility. For example, a text search tool that lets you choose a regular expression grammar that you are familiar with. You write one search algorithm using a single set of interfaces, but the instances of those interfaces are user-determined and decided at run time. For the most part, however, applications that depend on statically predefined regular expression have no use for such a facility. In addition, the facility as conceived in jakarta-oro is not quite analogous to commons-logging because multiple regular expression engines can coexist in the same application and are not automatically chosen for you, while it's my understanding that commons-logging dynamically chooses one underlying logging library (which makes sense for logging). In any case, if anyone who has an immediate need for dynamically pluggable regular expression engines is welcome to make the addition to jakarta-oro instead of waiting for us to get around to it. daniel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
