You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/03/08 10:48:53 UTC

[FlaconJX] problems with class references

Please look at this paste:
https://paste.apache.org/JfGh <https://paste.apache.org/JfGh>

memberType is a reference to a class.
description is a static getter on the class which returns an object with keys and getter names.

What equalsAllHelper() does is loop through the getters in both objects and make sure they are both equal.

This code should pass through unchanged to Javascript for this to function correctly:
if (!prop || !equalAllHelper(prop.memberType.description,o1val,o2val))

Instead it inserts code which makes a QName and throws a monkey wrench into the code.

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.

Harbs

Re: [FlaconJX] problems with class references

Posted by Harbs <ha...@gmail.com>.
> 
> Not sure what you mean by "importer classes have namespace declarations".
> What does that code look like?

This:
	internal class BaseTextLayoutImporter extends ConverterBase implements ITextImporter
	{
		private var _ns:Namespace;		// namespace of expected in imported/exported content
		
		private var _textFlowNamespace:Namespace; // namespace of the TextFlow element against which the namespaces of the following elements are validated

		public function BaseTextLayoutImporter(nsValue:Namespace, config:ImportExportConfiguration)
		{
			_ns = nsValue;
			_config = config;
		}

		public function get ns(): Namespace
		{
			return _ns;
		}

	public class TextLayoutImporter extends BaseTextLayoutImporter implements ITextLayoutImporter
	{
		public function TextLayoutImporter()
		{
			super(new Namespace("flow", "http://ns.adobe.com/textLayout/2008"), defaultConfiguration);
		}



> Are there any occurrences of two colons "::" in the source file?

With the exception of CONFIG::debug, this is it:

					var beginArrayChild:XML = xmlTree..*::BeginMissingElements[0];
					var endArrayChild:XML = xmlTree..*::EndMissingElements[0];
					var textLayoutMarkup:XML = xmlTree..*::TextFlow[0];

Harbs

Re: [FlaconJX] problems with class references

Posted by Alex Harui <ah...@adobe.com>.

On 3/9/17, 12:33 AM, "Harbs" <ha...@gmail.com> wrote:

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

Not sure what you mean by "importer classes have namespace declarations".
What does that code look like?

Are there any occurrences of two colons "::" in the source file?

Thanks,
-Alex

Re: [FlaconJX] problems with class references

Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ah...@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" <ah...@adobe.com> wrote:
>> 
>>> 
>>> 
>>> On 3/8/17, 2:48 AM, "Harbs" <ha...@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
>>> 
>> 
>

Re: [FlaconJX] problems with class references

Posted by Alex Harui <ah...@adobe.com>.
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" <ah...@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" <ah...@adobe.com> wrote:
>
>>
>>
>>On 3/8/17, 2:48 AM, "Harbs" <ha...@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
>>
>

Re: [FlaconJX] problems with class references

Posted by Alex Harui <ah...@adobe.com>.
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" <ah...@adobe.com> wrote:

>
>
>On 3/8/17, 2:48 AM, "Harbs" <ha...@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
>

Re: [FlaconJX] problems with class references

Posted by Alex Harui <ah...@adobe.com>.

On 3/8/17, 2:48 AM, "Harbs" <ha...@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