On Mon, Feb 1, 2010 at 3:09 PM, Thomas Broyer <[email protected]> wrote:
> Isn't translatable code generally going into /trunk/user/super, and
> the subpackage being called "translatable" rather than "super"?
>
Those are JRE and infrastructure super-source -- this is more user-level
code. Also, if you put them under user/super, you couldn't have a separate
module to import to pull it in, and RegExp would essentially be part of
Core.
And all those excludes="**/super/**" or similar later on wouldn't be
> needed.
>
The expectation is that over time other packages that are shared between
client and server, and that will need to be importable as a separate module.
> But actually I'm concerned that this hasn't been discussed at all on
> the list, ...
This is code that was being used internally getting migrated to GWT itself.
Most Googlers are used to working with internal tools and lists/waves, but
certainly we need to do a better job keeping the discussion in the open.
...and particularly that RegExp isn't a JSO so you cannot use
> the more performant JS literal notation to initialize a RegExp:
> public native RegExp myRegExp() /*-{ return /foo.*bar/gi; }-*/;
>
It is a JSO (see regexp/super/...) in the JS implementaiton, so you can do
exactly that. It is a pure Java version in the devmode and server
implementations so you can use RegExp in shared code.
> A generator-based initialization had been proposed on the issue
> tracker too:
> public interface MyRegExps extends RegExp {
> @RegExp("foo.*bar", "gi")
> RegExp myRegExp();
> }
>
Such a generator could be written for use with this RegExp implementation,
and is really orthogonal to it. However, there seems little to gain over
just using JSNI expressions as above.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
