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 >> >
