John, I'm agree with Thomas. RegExp integration should have been discussed in the list. It is landing into the trunk from nowhere for us... Since the 2.0 release, I feel that there is less interaction with the contrib list (btw what have been decided for the roadmap ?) and what we are supposed to see in the coming releases. We can understand that you prefer to use internal waves/lists but please let's not forget the "openess" nature of GWT that contribute to make this framework so popular
Sami On Mon, Feb 1, 2010 at 9:33 PM, John Tamplin <[email protected]> wrote: > 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 > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
