royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Royale compiler not handling Date.fullYear etc
Date Mon, 02 Jul 2018 15:36:25 GMT
Hi Andrew,

I agree with your conclusions.  Upon further investigation, Google Closure just closed those
bugs as duplicates and the original issue remains open.  So adding some field to the ExternCConfig
sounds like the easiest path for now.


´╗┐On 7/2/18, 2:14 AM, "Frost, Andrew" <> wrote:

    Even if we get the latest version, they still don't support a "readonly" annotation:
    lists the ones that are supported.
    And I tried updating to the newest jar file, got some weird errors so I think that way
would lead to a lot more work.
    We do get the original Javadoc comment come into our parsing function, so we could do
a free-text search for "@readonly" within this? Might be the simplest route until(?) Google
add this support properly..
    Alternatively you suggest using ExternCConfiguration: having looked into this, I think
the process would be:
    1) update the externc-config.xml file to include something like <field-readonly><class>Date</class><name>timezoneOffset</name></field-readonly>
 (so a bit like the "exclude" list where we don't include things like Array.toSource etc)
    2) update the file to handle this input field (like the "setExcludes"
handler for the "exclude" mapping..) and put in place a new "ReadOnlyMember" element and list
to hold this
    3) in the FieldReference.emit() method, check if this element is in the read-only property
list; if it is, treat it like an accessor but only with a 'get' method.
    So I'm thinking this latter approach is a nicer one and fits more with the rest of how
things are done... I'll update the pull requests later on after running through this and also
adding some tests...
    -----Original Message-----
    From: Alex Harui [] 
    Sent: 30 June 2018 08:00
    Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc
    Yeah, if @const becomes const in AS, that probably isn't right.
    I just found this:
    I don't have time to investigate further right now, so if you have time that would be
great.  We might need to update which version of Google Closure we are using.
    Regarding the options you listed, I think goal is to generate the right AS classes with
a getter and no setter.  If Google still doesn't handle @readonly, we could add a field to
the ExternCConfiguration where you specify which APIs should be read-only and correct the
output AS.
    On 6/29/18, 11:46 PM, "Frost, Andrew" <> wrote:
        Well @const is at least supported by the Google classes; with a slight change in
to actually set the internal flag ("this.isConst = comment.hasConstAnnotation();") then it
changes the ActionScript declaration so that it's now:
        public const timezoneOffset:Number = 13;
        And when you try to assign to it, you get 
        TestRoyale.mxml(38): col: 5 Error: Illegal assignment to a variable specified as constant.
        				date.timezoneOffset = 55;
        So it kind of works in flagging up a bad bit of code, but from an ActionScript perspective
it's not right, we should be getting an "AssignToReadOnlyPropertyProblem" rather than an "AssignToConstProblem".
        The options as I see it:
        1) live with this as a slightly incorrect warning, as it's very unlikely to happen
(shouldn't occur in the AS3 code to start with assuming that compiles already in Flex) and
it's the simplest/most elegant change
        2) have specific code in the SemanticUtils class which knows about this particular
Date property and is looking out for it by name ... not very efficient and something of a
        3) extend the closure compiler to support some of the other JSDoc annotations so that
we can generate property getters/setters and create read-only properties. Possibly the most
"correct" solution but not so good from a maintainability perspective if we have to change
the Google code...
        In terms of testing: as you said, the 'missing.js' in the royale-compiler folders
is for the compiler's testing, so if we add extra testing for the compiler with these new
properties then we need that file to also include those extra Date things. I guess it's not
a massive maintenance issue if these files are hardly ever changing.. I just wanted to be
sure I wasn't missing some step in the process that did an automatic sync from one to the
other. The same is true of the js.swc, it's being generated in the royale-typedefs folder
and currently I'm manually copying it to the royale-asjs folder... but for that one, there
must be something that copies it over, as that js/lib folder doesn't exist in the original
        -----Original Message-----
        From: Alex Harui [] 
        Sent: 30 June 2018 07:19
        Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc
        Interesting.  In
it mentions @const as the annotation.  That might already work and if not, we should probably
make it work.
        The missing.js in royale-compiler is just there to get the compiler's tests to run.
 The royale-typedefs repo has a dependency on royale-compiler, so we can't create a circular
dependency by having royale-compiler require royale-typedefs missing.js.  They don't need
to be kept in sync.  The royale-compiler version should be minimal.  The one in royale-typedefs
is intended to make a library with the right and complete Browser APIs.
        On 6/29/18, 3:55 PM, "Frost, Andrew" <> wrote:
            Those date tests already test the mapping, and are running fine. They're not getting
stuck at the earlier stage which is where the original problem lay. So I'd been thinking of
adding a new test file under the below folder, where other AS-specific testing is happening:
            In terms of the read-only properties, I would have hoped that the definition in
missing.js could be written:
             * @type {number}
             * @property
             * @readonly
            but the JSDoc parser isn't able to pick up/report upon the 'property' or 'readonly'
usage. We could add support for these perhaps, manually within the file
(which is where these properties are coming in currently) we could manually look for the "@property"
and/or "@readonly" tags within the comment.getOriginalCommentString() value; I would have
preferred to be able to call "comment.isReadOnly" or similar, but to get to that requires
changing Google's code..
            So yes, hold off doing anything with the pull requests for now, I'll see whether
I can get it to do things from the typedefs side of things...
            One extra note: I'm finding two "missing.js" files which aren't being kept in
sync at all (by the build tools); is this by design or should there be some kind of a link
between them?
            -----Original Message-----
            From: Alex Harui [] 
            Sent: 29 June 2018 17:38
            Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc
            There are Date tests in
            In this case, the issue may be in how to set up a copy of the tests to work with
js.swc instead of playerglobal.swc.
            Regarding read-only properties, I think the externc compiler might have a way
of doing that.  It would likely involve one of the JSDoc annotations or an interface.  And
the result should be a getter without a setter.  I don't have time to look for it right now.
 It would be best to deal with this in the typedefs instead of in the compiler, IMO.
            My 2 cents,
            On 6/29/18, 7:47 AM, "Frost, Andrew" <> wrote:
                ".. not yet" is probably the most appropriate response!!
                I had wondered whether it would need some formal self-tests adding, I'll have
a dig around to see how to do this bit :-)
                -----Original Message-----
                From: Harbs [] 
                Sent: 29 June 2018 13:35
                Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc
                Cool. Are there compiler tests for these Date additions?

View raw message