The only way I’ve ever seen XML (and QNames) constructed is with markup. The 
XML class constructs the QNames. (FWIW I implemented an optimization where it 
reuses QNames when possible because I was seeing that QNames were causing many 
MB of memory usage in XML heavy apps.)  I guess it is possible to instantiate 
and set the QName directly, but I’ve never seen an example (nor can I imagine a 
need) to do that.

That said, a bracket flag in QName might be the best solution.

> On Dec 29, 2018, at 7:37 PM, Alex Harui <[email protected]> wrote:
> 
> If you have an app using XML with non-default XML namespaces, how do you 
> write the code without using QName?  If it is true that QName is rarely 
> needed, then your plan becomes more reasonable.  And we could flip the 
> inheritance where QName extends XMLQName and the signatures in XML take 
> XMLQName.  It should be even more rare for QNames to be used in Royale since 
> more things should be public and not hidden in some custom namespace.
> 
> I think QName can only be used outside of XML in bracket syntax.  If that's 
> wrong, hopefully someone will tell us why.
> 
> -Alex 
> 
> On 12/29/18, 9:16 AM, "Harbs" <[email protected]> wrote:
> 
>    The flag idea sounds promising.
> 
>    As far as XMLQName goes, I was thinking that it would subclass Name and 
> the method signatures would still use Name. I don’t think it’s very common to 
> actually create a QName, so that would likely work.
> 
>    Of course having the overhead of a subclass every time a QName is 
> constructed is not ideal.
> 
>    My $0.02,
>    Harbs
> 
>> On Dec 29, 2018, at 9:26 AM, Alex Harui <[email protected]> wrote:
>> 
>> Well, I don't think we want to require folks to use XMLQName in their code.  
>> However, your idea of ClassQName made me think that maybe we can have the 
>> compiler set a flag on the QName whenever it is used in bracket syntax on 
>> non-XML.  I will try to remember to try that next week.
>> 
>> -Alex
>> 
>> On 12/28/18, 2:17 AM, "Harbs" <[email protected]> wrote:
>> 
>>   Gotcha.
>> 
>>   I think the simplest solution is to replace Name with XMLQName for XML. 
>> The other similar option is to create a ClassQName that the compiler would 
>> use instead of QName for namespaces in classes.
>> 
>>> On Dec 28, 2018, at 10:32 AM, Alex Harui <[email protected]> wrote:
>>> 
>>> Most URIs in QNames have something like: 
>>> "library://ns.adobe.com/mx/core/internal".  That is not a legal JavaScript 
>>> property name.  IOW, you can't run:
>>> 
>>>  someObject.library://ns.adobe.com/mx/core/internal::foo = 1;
>>> 
>>> So, we used to output bracket syntax:
>>> 
>>>  someObject["library://ns.adobe.com/mx/core/internal::foo"] = 1;
>>> 
>>> For getter/setters, this meant that the Object.defineProperties had entries 
>>> like:
>>> 
>>> { "library://ns.adobe.com/mx/core/internal::foo": {get: ... }}
>>> 
>>> And Closure started choking on it, so now we replace the "/", "." and ":" 
>>> with "$" or "_" to make it a legal JavaScript property name so we don't 
>>> have to use quotes and brackets.
>>> 
>>> But if you use a QName in property access outside of XML, the JavaScript 
>>> runtime calls QName.toString(), so it also has to return a string with the 
>>> same character replacements so it matches.  So what are the implications of 
>>> doing that?  I think inside of XML, we could test for QName and use 
>>> QName.match and/or use the unmodified URI.  Currently, the QName stores the 
>>> original URI, only toString() does the character replacements.  But if 
>>> someone has expectations on what QName.toString() returns, then that might 
>>> cause issues.
>>> 
>>> -Alex
>>> 
>>> On 12/27/18, 11:28 PM, "Harbs" <[email protected]> wrote:
>>> 
>>>  What are we modifying with the URI?
>>> 
>>>> On Dec 28, 2018, at 2:33 AM, Alex Harui <[email protected]> wrote:
>>>> 
>>>> Yeah, that's the sort of thing I was concerned about.  XML does call 
>>>> QName.toString() but it doesn't seem to actually care too much about what 
>>>> comes back.  In toXMLName it takes whatever name is and calls toString() 
>>>> on it.  The QName.toString() is different between SWF and JS.  It is only 
>>>> in JS that we modify the uri to be a valid JS property name.  We used to 
>>>> use bracket syntax, but that's what ClosureCompiler is choking on.
>>>> 
>>>> The question is what does someone do with myXML.name().toString()?  Are 
>>>> they matching it up against a URI?  They should be calling QName.match().
>>>> 
>>>> I couldn't immediately think of a way for QName to know it is being used 
>>>> for XML vs other properties.  We could create an XMLQName class for JS to 
>>>> return from name() that doesn't modify the URI.
>>>> 
>>>> -Alex
>>>> 
>>>> On 12/27/18, 1:04 PM, "Harbs" <[email protected]> wrote:
>>>> 
>>>> I don’t think we’re using toString() anywhere ourselves, but what happens 
>>>> if someone has myXML.name().toString()? (Or an implicit cast) Will this 
>>>> break their Flash code?
>>>> 
>>>>> On Dec 27, 2018, at 7:36 PM, Alex Harui <[email protected]> wrote:
>>>>> 
>>>>> Harbs,
>>>>> 
>>>>> I just changed QName.toString() to match the new namespace format the 
>>>>> compiler is outputting in order to make Google Closure Compiler happy.  
>>>>> Now I'm wondering if QName.toString() is used in Royale XML.
>>>>> 
>>>>> Thoughts?
>>>>> -Alex
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 

Reply via email to