I wanted to ask the list a question, since we've looped back to an old
discussion at
http://code.google.com/p/google-web-toolkit/wiki/ResourceOracle about how to
treat overlapping source modules.

The question is what to do if a GWT App inherits two (or more) modules that
have selective source inclusion in a given Java package.  That is, they
don't just include *.java, but have some combination of <include> and
<exclude> subtags.  What we do now is that the last-specified wins, which is
pretty clearly wrong; what we proposed a while ago is a fairly complicated
idea that nods to backwards compatibility of that broken spec; what I'm
arguing for is a setwise union.  I'd be interested to know what a broader
straw poll would expect, and what use cases people can imagine for this.

The first question is why you wouldn't just use *.java; I've thought of two
reasons for that:

   - Avoiding non-translatable code; in most cases, ideally, you'd just
   refactor a "shared" package, but I've seen cases where shared DTOs were in
   server packages, or where a previously vanilla Java library like
   google-collections <http://code.google.com/p/google-collections/> was
   retroactively partially used in GWT.  (Note that I don't necessarily
   advocate this; I'm not sure the google-collections was being *efficient* in
   GWT, only that it was being used!  Rodrigo's working on some collections
   stuff that should promise efficiency in both languages.)
   - Selective component inclusion, for example if you have a bunch of small
   widgets in one foo.client.widgets package but want to inherit them
   individually; your app might use one module pulling WidgetOne.gwt.xml and a
   second module pulling SomethingElse.gwt.xml, both with different subsets of
   foo.client.widgets

One might argue that both "should" be solved by refactoring into different
packages, but I can understand why one might not in those two cases.


And next, I've thought of two use cases for the merging:

   - Src and test packages, which are generally in the same Java package,
   - Again, the selective library inclusion

But, it seems to me, that in all of those cases you end up wanting union.
 If A inherits B and C, B includes Foo.java, and C excludes Foo.java, you
want A to see Foo.java 'cause it needs B and B needs Foo.

So C's "exclusion" means "I don't need Foo unless something else does," not
 "I can't accept Foo; keep it away from me."


I haven't come up with a scenario for the "keep it away from me"
interpretation, except those in which you're already toast.  Anyone else?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

To unsubscribe, reply using "remove me" as the subject.

Reply via email to