What John said.  Blame Java for the fact that with some lookup oracle, it's
impossible to distinguish the cases.  We've always assumed that users would
not use '$' in class names in places where it matters.

That being said, let's assume that a user isn't allowed to have both A.B and
A$B like Toby said, as the binary names would collide.  Given that, I
*think* the only place source type name really matters is resolving rebind
requests and results.  So maybe it's possible we could use only binary name
or internal name everywhere and move away from using source name except in
output messages.

On Fri, May 27, 2011 at 9:50 AM, John Tamplin <j...@google.com> wrote:

> On Fri, May 27, 2011 at 4:45 AM, Grzegorz Kossakowski <
> grzegorz.kossakow...@gmail.com> wrote:
>
>> 2011/5/26 Eric Ayers <zun...@google.com>:
>> > Unfortunately, I tried removing the replace('$',".") and it failed
>> > miserably.  Looking at it in the debugger, those really are binary
>> names.
>> > e.g.:
>> > com.google.gwt.core.client.impl.AsyncFragmentLoader$LoadingStrategy
>>
>> Thanks guys for you answers. I moved on with my work-around. It would
>> be great if those binary names were converted to source names as soon
>> as possible so number of places in gwt code where we have to consider
>> both options is minimized.
>>
>
> The problem is conversion to source names is lossy -- given Foo.Bar.Baz,
> you don't know where the split between the package name, enclosing class
> name, and class name is (compare to Foo/Bar$Baz and Foo/Bar/Baz).  I think
> the only way you could avoid this problem is if you kept a structured type
> with those pieces of information rather than a simple string, but that would
> be expensive in terms of allocating several additional objects for every
> class name in the program, plus many uses don't care about the distinctions
> and just wand the source name.
>
> --
> 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

Reply via email to