I just took a look at UIDUtil.
If I dump Core.SWC, the UIDUtil.js in there has the following:
goog.provide('org.apache.flex.utils.UIDUtil');
/* FlexJS Static Dependency List: org.apache.flex.utils.BinaryData*/
goog.require('org.apache.flex.utils.BinaryData');
goog.require('org.apache.flex.utils.Language');
Then, after -remove-circulars is used to build HelloWorldTLF the UIDUtils
in bin/js-debug has the following:
goog.provide('org.apache.flex.utils.UIDUtil');
/* FlexJS Static Dependency List: org.apache.flex.utils.BinaryData*/
goog.require('org.apache.flex.utils.BinaryData');
This should cause BinaryData to be loaded before UIDUtil.
Are you getting the same results?
Thanks,
-Alex
On 4/8/17, 10:04 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> On Apr 9, 2017, at 12:50 AM, Alex Harui <aha...@adobe.com> wrote:
>>
>> I assume this is only a problem for folks using -remove-circulars?
>>
>I have not tested with remove-circulars truned off, so very possibly, yes.
>
>> I assume what is broken is the order of loaded files instead of
>>something
>> else?
>
>Correct. With the current status of remove-circulars, the only reliable
>way to deal with static values which are non-primitive are to use getters
>instead of static initializations.
>
>> Thanks,
>> -Alex
>>
>> On 4/8/17, 9:46 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>>> Related issue:
>>>
>>> The recent changes to Falcon has broken UIDUtil which has the
>>>following:
>>> private static const UIDBuffer:BinaryData = new BinaryData();
>>>
>>> Unless something changes, this needs to be changed to a getter.
>>>
>>>> On Apr 8, 2017, at 11:40 PM, Harbs <harbs.li...@gmail.com> wrote:
>>>>
>>>> Currently initializing non-primitive static types are a big no-no in
>>>> FlexJS. It causes all kinds of javascript runtime errors due to
>>>> non-defined types depending on the order of loaded files.
>>>>
>>>> I think this is an area which needs some improvement. The improvement
>>>> can take two variations:
>>>>
>>>> 1. We can simply disallow initializing non-primitive types at compile
>>>> time, so at least there will be a compile-time warning of potential
>>>> problems.
>>>> 2. We can somehow allow these initializations.
>>>>
>>>> I’m not sure if #2 is possible, but it would definitely be preferred
>>>>to
>>>> #1 if it is.
>>>>
>>>> Thoughts?
>>>>
>>>> Harbs
>>>
>>
>
