I have already removed tlf_internal from the entire code base. I’m not sure where the QName is coming from. The importer classes have namespace declarations, maybe that’s throwing a spanner into the works?
I don’t see this as a very high priority issue if simple cases work. > On Mar 9, 2017, at 7:35 AM, Alex Harui <aha...@adobe.com> wrote: > > I can't seem to reproduce this in a small test. In theory, the only code > that outputs "new QName" would be in response to a namespace token like > mx_internal::someProperty. > > I see in original TLF code the call has "tlf_internal::description", but > in your example, it is just "description". Can you delete the output to > make sure the compiler really is generating "new Qname" from just > "description"? > > Thanks, > -Alex > > On 3/8/17, 5:19 PM, "Alex Harui" <aha...@adobe.com> wrote: > >> It appears there is more to it. The class that owns memberType also has a >> tlf_internal::description field which is confusing the fetching of >> memberType.description. >> >> Are you going to be leveraging tlf_internal namespaces in the port? That >> hasn't been fully debugged and will not generated small code. >> >> -Alex >> >> On 3/8/17, 3:28 PM, "Alex Harui" <aha...@adobe.com> wrote: >> >>> >>> >>> On 3/8/17, 2:48 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> Please look at this paste: >>>> https://paste.apache.org/JfGh <https://paste.apache.org/JfGh> >>>> >>>> Changing the type of memberType to “*” resolves this issue for me, but >>>> the question is whether this is a bug which should be fixed, or a >>>> limitation that requires a work-around. >>> >>> That's a bug. "public" should never end up in a Qname. I'll see if I >>> can >>> reproduce it. >>> >>> Thanks, >>> -Alex >>> >> >
