commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: Proposed Contribution to Apache Commons,
Date Fri, 02 Oct 2015 18:46:06 GMT
I do not have time to dig into this one ATM but I'd like to give my 2c.

Does this project introduce a new RE-like language or is it an API wrapper
for REs? It sounds like it is both.

A project like this I could see in Commons if the project was split into an
API module and modules for different pattern matching languages, where the
standard Java RE would be the reference example. Naomi (I love the name
BTW, someones wife or daughter?) would be another implementation module.
With both under its belt, the project would be on fairly solid footing
(granted I do not know Naomi). You could even imaging implementations that
would accept a JXPath or a SQL WHERE clause.

If the project is only meant to introduce a new RE-like language, then a
TLP would be probably more appropriate.


On Thu, Oct 1, 2015 at 11:58 PM, Henri Yandell <> wrote:

> On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz <>
> wrote:
> > On 9/29/15 3:55 PM, Gary Gregory wrote:
> > > Norman,
> > >
> > > Hello and welcome to Apache Commons.
> > >
> > > It's not clear to me why Naomi is better than regular expressions.
> > Pointing
> > > to Javadocs is not the best way to get traction.
> > >
> > > Your project would be better served by having some documentation on
> your
> > > front page with an example driven tutorial.
> > >
> > > Is Naomi faster than REs?
> > >
> > > What can I do in Naomi that REs can't do? And vice-versa.
> > >
> > > Examples of this on your front page would help you at least get folks
> to
> > > consider learning a brand new way of doing things...
> >
> > +1
> > The code in SimpleExamples starts to get to this.  Looks interesting
> > and powerful.  Either here or on the github readme you should take a
> > stab at explaining a little more how hard problems using regex get
> > easier with naomi, illustrated with some simple examples.  Then
> > maybe with help from community members here, you can develop some
> > overview / getting started docs that help people get into the code.
> >
> +1.
> Reading SimpleExamples, my summary would be a boilerplate description of
> "It replaces the arcane regular expression language with an API". It
> reminds me of command line argument parsers. Perl had/has a great regular
> expression like command line argument parser, but it was cryptic and you
> either loved it or hated it. Then along came Commons CLI, args4j and all
> the others, providing a more OO/procedural API instead of its own mini
> language. Not as 'powerful' (in that you had to type more), but simpler (in
> that you didn't have to learn a new lingo and didn't have to juggle
> multiple languages inside one context (a source file)).
> I definitely need that user manual. It's hard, with a brain trained on
> regular expressions, to read 'Pattern greek3=new CharSequencePattern("?")'
> and realize (I think) that it means a literal ? character. It's also the
> primary way it'll be successful. You need that educational path that
> explains what a ExplicitCharClass is for, rather than randomly clicking on
> javadoc :)
> There'll also be much debate to be had I suspect. Is "a-e" too complex,
> compared to "abcde" or "a","e". Which parts of regex are worth supporting,
> vs not. Can I mix bits of regexp with bits of Naomi?   new
> ExplicitCharClass("a-eg-p").
> Random.... I'd like the idea of varargs for automatic and'ing. ie:
> new ExplicitCharClass("a-p", "!f")   [and is a not char class too
> complex?].
> Continuing on my summary, as I peruse the code a little more, I'd go with:
> "Build a regular expression via an API, not an arcane language of its own".
> I'd love to see that grow to:
> "Express regular expressions as objects, or mix and match objects with that
> arcane mini language we all love or loathe".
> Hen

E-Mail: |
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition <>
Spring Batch in Action <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message