Hi,

There was one place in the name mangling that I had to leave an ugly
replacement:

https://github.com/stephenh/scalagwt-gwt/blob/embed/dev/core/src/com/google/gwt/dev/javac/CompilationStateBuilder.java#L109

allValidClasses is by internal name now, but the qualified references
coming from ecj are by source name.

(Hm, if these are top-level only units, then a simple replacement would
be okay.  Does anyone know if that is the case, off the top of their
heads? I'll fire up the debugger later and see if I can tell.)

But the other reason I ask on the list instead of in the review is that,
for scalagwt itself, I don't have these ecj data structures, so I'm
inferring the simple and qualified refs from the api refs:

https://github.com/stephenh/scalagwt-gwt/blob/embed/dev/core/src/com/google/gwt/dev/javac/Dependencies.java#L62

I'm pretty sure this approach is okay, but my concern is that, poking
around in the debugger, ecj, ends up with a whole lot more strings as
simple/qualified refs than my current, albeit somewhat naive approach
in buildFromApiRefs.

Given I'd already written buildFromApiRefs, I was tempted to use it
for the .java files as well, since api refs are already internal names,
and then I could remove the source -> internal mangling. But I didn't
have enough confidence to do that just yet.

If anyone could comment on buildFromApiRefs, both in theory and the
current implementation, just for scalagwt but also whether it's
potentially usable for the java side, I'd appreciate it.

But I'll nonetheless look into whether the qualifiedReferences are
only top-level units, in which case the name mangling should be okay.
I didn't think of that until just now.

- Stephen


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

Reply via email to