You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2018/12/27 17:36:16 UTC
Royale XML and QNames
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
Re: Royale XML and QNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I went to add a flag and realized we can just as easily call some method that returns a properly modified string. At least, in the places we know QName is used. I just pushed those changes and the thing that was broken is still working so we'll see if anything else breaks. QName.toString() is back to returning the URI unmodified.
-Alex
On 12/29/18, 9:59 AM, "Harbs" <ha...@gmail.com> wrote:
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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@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" <ha...@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 <ah...@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" <ha...@gmail.com> wrote:
>>>
>>> What are we modifying with the URI?
>>>
>>>> On Dec 28, 2018, at 2:33 AM, Alex Harui <ah...@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" <ha...@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 <ah...@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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Royale XML and QNames
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@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" <ha...@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 <ah...@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" <ha...@gmail.com> wrote:
>>>
>>> What are we modifying with the URI?
>>>
>>>> On Dec 28, 2018, at 2:33 AM, Alex Harui <ah...@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" <ha...@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 <ah...@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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Royale XML and QNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> 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 <ah...@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" <ha...@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 <ah...@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" <ha...@gmail.com> wrote:
>>
>> What are we modifying with the URI?
>>
>>> On Dec 28, 2018, at 2:33 AM, Alex Harui <ah...@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" <ha...@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 <ah...@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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Royale XML and QNames
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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" <ha...@gmail.com> wrote:
>>
>> What are we modifying with the URI?
>>
>>> On Dec 28, 2018, at 2:33 AM, Alex Harui <ah...@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" <ha...@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 <ah...@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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Royale XML and QNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <ha...@gmail.com> wrote:
>
> What are we modifying with the URI?
>
>> On Dec 28, 2018, at 2:33 AM, Alex Harui <ah...@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" <ha...@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 <ah...@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
>>>
>>
>>
>>
>
>
>
Re: Royale XML and QNames
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@gmail.com> wrote:
>
> What are we modifying with the URI?
>
>> On Dec 28, 2018, at 2:33 AM, Alex Harui <ah...@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" <ha...@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 <ah...@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
>>>
>>
>>
>>
>
>
>
Re: Royale XML and QNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> wrote:
What are we modifying with the URI?
> On Dec 28, 2018, at 2:33 AM, Alex Harui <ah...@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" <ha...@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 <ah...@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
>>
>
>
>
Re: Royale XML and QNames
Posted by Harbs <ha...@gmail.com>.
What are we modifying with the URI?
> On Dec 28, 2018, at 2:33 AM, Alex Harui <ah...@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" <ha...@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 <ah...@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
>>
>
>
>
Re: Royale XML and QNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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
>
Re: Royale XML and QNames
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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
>