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 <aha...@adobe.com.INVALID> 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" <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID> 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" <harbs.li...@gmail.com> wrote:
>>
>> What are we modifying with the URI?
>>
>>> On Dec 28, 2018, at 2:33 AM, Alex Harui <aha...@adobe.com.INVALID> 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" <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID> 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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
