<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Thanks Mark!<br>
    <br>
    Let's go with UNICODE_PROPERTY, if there is no objection.<br>
    <br>
    -Sherman<br>
    <br>
    On 4/24/2011 9:00 PM, Mark Davis ☕ wrote:
    <blockquote
      cite="mid:BANLkTinkeyZR6P9VkeBgjSdMxCFgzd-qAA@mail.gmail.com"
      type="cite">
      <div><font class="Apple-style-span" face="georgia, serif">There
          are pluses and minuses to any of them: </font><span
          class="Apple-style-span" style="font-family: georgia,serif;">UNICODE_SPEC,
          UNICODE_PROPERTY, UNICODE_CLASS, UNICODE_PROPERTIES,
          or UNICODE_CLASSES, although any would work in a pinch.</span></div>
      <div><span class="Apple-style-span" style="font-family:
          georgia,serif;"><br>
        </span></div>
      <div><span class="Apple-style-span" style="font-family:
          georgia,serif;">I'd favor a bit the singular over the plural,
          given the usage.</span></div>
      <div><span class="Apple-style-span" style="font-family:
          georgia,serif;"><br>
        </span></div>
      <div><span class="Apple-style-span" style="font-family:
          georgia,serif;">The term 'class' is not used much in Unicode,
          just for two properties (see below). So someone could possibly
          think it just meant those two properties, and it</span><span
          class="Apple-style-span" style="font-family: georgia,serif;"> could
          cause a bit of confusion with 'class' meaning OO. So for that
          reason I don't think CLASS(ES) would be optimal.</span></div>
      <meta charset="utf-8">
      <div><span class="Apple-style-span" style="font-family:
          georgia,serif;">
          <meta charset="utf-8">
          <span class="Apple-style-span" style="font-family: Georgia;
            font-size: medium;">
            <pre style="word-wrap: break-word; white-space: pre-wrap;">bc        ; Bidi_Class
ccc       ; Canonical_Combining_Class</pre>
          </span></span></div>
      <div><font class="Apple-style-span" face="georgia, serif"><a
            moz-do-not-send="true"
            href="http://unicode.org/Public/UNIDATA/PropertyAliases.txt">http://unicode.org/Public/UNIDATA/PropertyAliases.txt</a></font></div>
      <meta charset="utf-8">
      <div><font class="Apple-style-span" face="georgia, serif"><br>
        </font></div>
      <div>
        <div><font face="georgia, serif">Mark<br>
            <br>
            <i>— Il meglio è l’inimico del bene —</i></font><br>
          <br>
          <br>
          <div class="gmail_quote">On Sun, Apr 24, 2011 at 11:22,
            Xueming Shen <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:xueming.shen@oracle.com">xueming.shen@oracle.com</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
              0.8ex; border-left: 1px solid rgb(204, 204, 204);
              padding-left: 1ex;">
              <div bgcolor="#ffffff" text="#000000"> <br>
                Two more names, UNICODE_PROPERTIES and UNICODE_CLASSES,
                are suggested.<br>
                 <br>
                any opinion?<br>
                <br>
                -Sherman
                <div>
                  <div class="h5"><br>
                    <br>
                    On 4/23/2011 6:50 PM, Xueming Shen wrote:
                    <blockquote type="cite"> Forwarding...forgot to
                      include the list.<br>
                      <br>
                      -------- Original Message --------
                      <table border="0" cellpadding="0" cellspacing="0">
                        <tbody>
                          <tr>
                            <th valign="BASELINE" align="RIGHT"
                              nowrap="nowrap">Subject: </th>
                            <td>Re: Codereview Request: 7039066 j.u.rgex
                              does not match TR#18 RL1.4 Simple Word
                              Boundaries and RL1.2 Properties</td>
                          </tr>
                          <tr>
                            <th valign="BASELINE" align="RIGHT"
                              nowrap="nowrap">Date: </th>
                            <td>Sat, 23 Apr 2011 17:53:42 -0700</td>
                          </tr>
                          <tr>
                            <th valign="BASELINE" align="RIGHT"
                              nowrap="nowrap">From: </th>
                            <td>Xueming Shen <a moz-do-not-send="true"
                                href="mailto:xueming.shen@oracle.com"
                                target="_blank">&lt;xueming.shen@oracle.com&gt;</a></td>
                          </tr>
                          <tr>
                            <th valign="BASELINE" align="RIGHT"
                              nowrap="nowrap">To: </th>
                            <td>Tom Christiansen <a
                                moz-do-not-send="true"
                                href="mailto:tchrist@perl.com"
                                target="_blank">&lt;tchrist@perl.com&gt;</a></td>
                          </tr>
                        </tbody>
                      </table>
                      <br>
                      <br>
                      <pre> Mark, Tom,

I agree with Mark that UNICODE_SPEC is a better name than  
UNICODE_CHARSET. We will have to deal with
the "compatibility" issue Tom mentioned anyway anyway should Java go 
higher level of Unicode Regex support
someday. New option/flag will have to be introduced to let the developer 
to have the choice, just like what we
are trying to do with the ASCII only or Unicode version for those classes.

I also agree we should have an embedded flag. was thinking we can add it 
later, for example the JDK8, if we
can get this one in jdk7, but the Pattern usage in String class is 
persuasive.

The webrev, specdiff and Pattern doc have been updated to use 
UNICODE_SPEC as the flag and (?U) as the
embedded flag. It might be a little confused, compared to we use (?u) 
for UNICODE_CASE, but feel it might
feel "nature" to have uppercase "U" for broader Unicode support.

The webrev is at
<a moz-do-not-send="true" href="http://cr.openjdk.java.net/%7Esherman/7039066/webrev/" target="_blank">http://cr.openjdk.java.net/~sherman/7039066/webrev/</a>

 j.u.regex.Pattern API:
<a moz-do-not-send="true" href="http://cr.openjdk.java.net/%7Esherman/7039066/Pattern.html" target="_blank">http://cr.openjdk.java.net/~sherman/7039066/Pattern.html</a>

Specdiff:
<a moz-do-not-send="true" href="http://cr.openjdk.java.net/%7Esherman/7039066/specdiff/diff.html" target="_blank">http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html</a>

Tom,  it would be appreciated if you can at lease give the doc update a 
quick scan to see if I miss anything.
And thanks for the suggestions for the Perl related doc update, I will 
need go through it a little later and address
it in a separate CR.

Thanks,
-Sherman


On 4/23/2011 10:48 AM, Tom Christiansen wrote:
&gt; Mark Davis ☕<a moz-do-not-send="true" href="mailto:mark@macchiato.com" target="_blank">&lt;mark@macchiato.com&gt;</a>  wrote
&gt;     on Sat, 23 Apr 2011 09:09:55 PDT:
&gt;
&gt;&gt; The changes sound good.
&gt; They sure do, don't they?  I'm quite happy about this.  I think it is more
&gt; important to get this in the queue than that it (necessarily) be done for
&gt; JDK7.  That said, having a good tr18 RL1 story for JDK7's Unicode 6.0 debut
&gt; makes it attractive now.  But if not now, then soon is good enough.
&gt;
&gt;&gt; The flag UNICODE_CHARSET will be misleading, since
&gt;&gt; all of Java uses the Unicode Charset (= encoding). How about:
&gt;&gt;        UNICODE_SPEC
&gt;&gt; or something that gives that flavor.
&gt; I hadn't thought of that, but I do see what you mean.  The idea is
&gt; that the semantics of \w etc change to match the Unicode spec in tr18.
&gt;
&gt; I worry that UNICODE_SPEC, or even UNICODE_SEMANTICS, might be too
&gt; broad a brush.  What then happens when, as I imagine it someday shall,
&gt; Java gets full support for RL2.3 boundaries, the way with ICU one uses
&gt; or (?w) or UREGEX_UWORD for?
&gt;
&gt; Wouldn't calling something UNICODE_SPEC be too broad? Or should
&gt; UNICODE_SPEC automatically include not just existing Unicode flags
&gt; like UNICODE_CASE, but also any UREGEX_UWORD that comes along?
&gt; If it does, you have back-compat issue, and if it doesn't, you
&gt; have a misnaming issue.  Seems like a bit of a Catch22.
&gt;
&gt; The reason I'd suggested UNICODE_CHARSET was because of my own background
&gt; with the names we use for this within the Perl regex source code (which is
&gt; itself written in C).  I believe that Java doesn't have the same situation
&gt; as gave rise to it in Perl, and perhaps something else would be clearer.
&gt;
&gt; Here's some background for why we felt we had to go that way. To control
&gt; the behavior of \w and such, when a regex is compiled, a compiled Perl
&gt; gets exactly one of these states:
&gt;
&gt;      REGEX_UNICODE_CHARSET
&gt;      REGEX_LOCALE_CHARSET
&gt;      REGEX_ASCII_RESTRICTED_CHARSET
&gt;      REGEX_DEPENDS_CHARSET
&gt;
&gt; That state it normally inherits from the surrounding lexical scope,
&gt; although this can be overridden with /u and /a, or (?u) and (?a),
&gt; either within the pattern or as a separate pattern-compilation flag.
&gt;
&gt; REGEX_UNICODE_CHARSET corresponds to out (?u), so \w and such all get the
&gt; full RL1.2a definitions.  Because Perl always does Unicode casemapping --
&gt; and full casemapping, too, not just simple -- we didn't need (?u) for what
&gt; Java uses it for, which is just as an extra flavor of (?i); it doesn't
&gt; do all that much.
&gt;
&gt;      (BTW, the old default is *not* some sort of non-Unicode charset
&gt;      semantics, it's the ugly REGEX_DEPENDS_CHARSET, which is Unicode for
&gt;      code points&gt;  255 and "maybe" so in the 128-255 range.)
&gt;
&gt; What we did certainly isn't perfect, but it allows for both backwards
&gt; compat and future growth.  This was because people want(ed) to be able to
&gt; use regexes on both byte arrays yet also on character strings.  Me, I think
&gt; it's nuts to support this at all, that if you want an input stream in (say)
&gt; CP1251 or ISO 8859-2, that you simply set that stream's encoding and be
&gt; done with it: everything turns into characters internally.  But there's old
&gt; byte and locale code out there whose semantics we are loth to change out
&gt; from under people.  Java has the same kind of issue.
&gt;
&gt; The reason we ever support anything else is because we got (IMHO nasty)
&gt; POSIX locales before we got Unicode support, which didn't happen till
&gt; toward the end of the last millennium.  So we're stuck supporting code
&gt; well more than a decade old, perhaps indefinitely.  It's messy, but it
&gt; is very hard to do anything about that.  I think Java shares in that
&gt; perspective.
&gt;
&gt; This corresponds, I think, to Java needing to support pre-Unicode
&gt; regex semantics on \w and related escapes.  If they had started out
&gt; with it always means the real thing the way ICU did, they wouldn't
&gt; need both.
&gt;
&gt; I wish there were a pragma to control this on a per-lexical-scope basis,
&gt; but I'm don't enough about the Java compilers internals to begin to know
&gt; how to go about implementing some thing like that, even as a
&gt; -XX:+UseUnicodeSemantics CLI switch for that compilation unit.
&gt;
&gt; One reason you want this is because the Java String class has these
&gt; "convenience" methods like matches, replaceAll, etc, that take regexes
&gt; but do not provide an API that admits Pattern compile flags.  If there
&gt; is no way to embed a (?U) directive or some such, nor any way to pass
&gt; in a Pattern.UNICODE_something flag.  The Java String API could also
&gt; be broadened through method signature overloading, but for now, you
&gt; can't do that.
&gt;
&gt; No matter what the UNICODE_something gets called, I think there needs to be
&gt; a corresponding embeddable (?X)-style flag as well.  Even if String were
&gt; broadened, you'd want people to be able to specify *within the regex* that
&gt; that regex should have full Unicode semantics.  After all, they might read
&gt; the pattern in from a file.  That's why (most) Pattern.compile flags need
&gt; to be able to embedded, too.  But you knew that already. :)
&gt;
&gt; --tom

</pre>
                    </blockquote>
                    <br>
                  </div>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>