I would go the other way and say that the people who designed the Java
regex library made a serious error when they decided not to adopt the Perl
regex syntax.
Some other people agree with me, because ther are several Java PCRE (Perl-
compatible regex) libraries out there, in particular, one sponsored by
the Apache Foundation:
I’d be inclined not to use java.util.regex at all, in favor of something
like this. Anyone who knows regexes is going to be annoyed by what Java
provides, and anyone who doesn’t know regexes won’t use them anyway, or
at least won’t have an opinion.
However, your statement ‘and anyone who doesn’t know regexes won’t use them anyway’ is not quite true. I know for a fact that regexps have been used in a number of modules in a basic form by a few of us people who don’t know how to use them. If, for instance, you where suddenly to enforce the need for ‘/’ delimiters on the expression, it will break plenty of modules.
In the mid to longer term, I want to completely replace the current Property Expression mechanism by a BeanShell solution that will fix a whole bucket load of problems with the current implementation. Perhaps we leave it as it is for now and fix it as part of this?
I have just started overhauling all of my Beanshell stuff for 3.2. I had planned just to introduce Calculated Properties, and inline Java expressions, but I should be able to do the Property Expressions also.
This is one of those things which we’ll be in a better position to fix
globally if we need to once we’re on the new site and we have somebody
looking after the module library…
Anyway, it would be better for people who don’t know regexes to learn
the standard kind, rather than the weird java.util.regex ones.
I had only stumbled onto the Pattern.matches() vs. Matcher.find() problem. Are you saying that there is another issue with Perl5 regex syntax not being used properly in java.util.regex? That would be odd… Do you have an example of a difference?
Now that I look back to find my example of that, I realized that it’s not
because the regex syntax is not PCRE, but rather because you have to guard
every blasted backslash in Java Strings. Using a different regex library
would not save us from such uglies as “\s*\d+\\d+\s*”, because Java
doesn’t support uninterpreted strings (for which you use single quotes in
Perl).
What about the VASSAL code doing that for the user? Should be pretty simple, yes? That way the module designer would use normal regex syntax, and behind the scenes it would be escaped for them…
The doubled-backslash is only an issue for Java code that programmers
write. Since that has to conform to the syntax rules for Java strings.
For backslashes that are entered into, say, a text field in a Swing
input form, the doubling will already be done for you. So the typical
end-user won’t see that.