No worries.  I didn't see it either.  The Flash environment picked it up.

It also picked up that some of the tests may not be properly implemented.  The 
date test is using 'Sat Jun 30 23:59:59 GMT-0800 2018' and then Date.date+=1, 
but when you have the Flash SDK, it actually runs this code and it isn't doing 
the right thing, at least in my time zone.  I'm looking into that now.

It is hard to write tests for different time zones and different runtime 
environments.  I'm glad you got us most of the way there.

Later,
-Alex

On 7/3/18, 10:03 AM, "Frost, Andrew" <[email protected]> wrote:

    Arg! Sorry, missed those when I was looking at the AS3 documentation...
    
    I've not set my environment up to generate the SWF outputs, I might do that 
just for completion and to try to avoid such issues in the future!
    
    Thanks
    
       Andrew
    
    
    -----Original Message-----
    From: Alex Harui [mailto:[email protected]] 
    Sent: 03 July 2018 17:46
    To: [email protected]
    Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc
    
    One glitch did show up after the merge, however.  The tests as configured 
will be run against playerglobal.swc for folks who are configured with the 
Flash/AIR SDKs.  I was expecting some other error, but the first thing it 
caught was that Date.day and Date.dayUTC are also read-only (makes sense given 
that it would not be obvious what to do if you change Tuesday to Wednesday.  It 
could be any Wednesday).
    
    So I am going to add those two to the readonly list and update the tests to 
expect errors.  I will probably worry about making this set of tests always run 
against the JS-only config some other day.  Maybe you or some other volunteer 
wants to deal with it.  Probably not that important, IMO.
    
    Anyway, still a great job and thanks for contributing.
    
    -Alex
    
    On 7/3/18, 9:31 AM, "Alex Harui" <[email protected]> wrote:
    
        Hi Andrew,
        
        I just accepted your pull requests.  Great Job!
        
        Yes, I know it was more work than expected, but actually you did a lot 
more than just handle Date APIs.  You provided a way to specify readonly vars 
in externs and provided a pile of new tests.
        
        Hope to see more contributions like these.
        
        Thanks,
        -Alex
        
        On 7/3/18, 3:57 AM, "Frost, Andrew" <[email protected]> wrote:
        
            Another update: the swfdumps are all done and it's all working fine 
and testing itself properly, I had to change another externc-config.xml file 
along with the other missing.js file to ensure that the 'testing' libraries are 
[roughly] equivalent to the actual files used in compilation..
            
            Seems to be working to me and, I hope, is an acceptable solution. 
It required a lot more changes than I'd originally thought!
            
            Pull requests are:
            Typedefs: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FH8du73qyd2P59dgc_NBig5kKS-MSuqeeLzkLnUuGc2g%3D%3Fd%3DXVM8wcUx4AVvvnx4aYpF00yk_Eyt9QZZF_c65XW-bGLlOqoBAmP4EZZZHcq3CxBBmKZpgajW8vxVFLmNQUwTkz-h3EmNKlq8UyFiYyklTfyKmivIVAaXa-6Uh22WNmrQPgipIQ5Bl1dYRZXx8v2FZ83ZkYErcY9kwfeFH2td0tJLDs3UuRtInu7Pg3ez7ZpidUYN_NR6xuesnpZ1PdAMKNZA0LhumZmir0NVprDmnsJ1BkaWAy6vXkO3GNuS4KHFrBe1VUQvY5uWuwGnqkMRvZA1N-hVF8cfY4bUQjZbFWjb9oxrU7AbQrtv2GodpVQWdsNUjpiczlfhcvVk8VhPuVjsGma93Tj8zXHuFsMOZxZYg1sTepHUbWoMXGQVGUmK1Jk6EAJ7zyL4lVjxzkNAJ31si4DjoouXLo5Q-D0w0B2oRQ14_ii9MfaNRuJ93qk%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252Fapache%25252Froyale-typedefs%25252Fpull%25252F2%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C23fabd6b67b94e1dc16008d5e0d3d550%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636662122786567530%2526sdata%253DQ%25252FnpJJ657LMOQFUvytn5k4LWbVVw3YancGcyqU%25252F9MSI%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7Cd39e10024e8d42b49b5008d5e106e101%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662342019465396&sdata=YRzeG0EY17vQ7gX3UYr2T7oJIBjTICGoRc3fdXjVkTI%3D&reserved=0
            Compiler: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2F7ckP0xBvPXAikG7TS7fGtLEmtYORNspA7ffmJ61oStE%3D%3Fd%3DXVM8wcUx4AVvvnx4aYpF00yk_Eyt9QZZF_c65XW-bGLlOqoBAmP4EZZZHcq3CxBBmKZpgajW8vxVFLmNQUwTkz-h3EmNKlq8UyFiYyklTfyKmivIVAaXa-6Uh22WNmrQPgipIQ5Bl1dYRZXx8v2FZ83ZkYErcY9kwfeFH2td0tJLDs3UuRtInu7Pg3ez7ZpidUYN_NR6xuesnpZ1PdAMKNZA0LhumZmir0NVprDmnsJ1BkaWAy6vXkO3GNuS4KHFrBe1VUQvY5uWuwGnqkMRvZA1N-hVF8cfY4bUQjZbFWjb9oxrU7AbQrtv2GodpVQWdsNUjpiczlfhcvVk8VhPuVjsGma93Tj8zXHuFsMOZxZYg1sTepHUbWoMXGQVGUmK1Jk6EAJ7zyL4lVjxzkNAJ31si4DjoouXLo5Q-D0w0B2oRQ14_ii9MfaNRuJ93qk%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252Fapache%25252Froyale-compiler%25252Fpull%25252F46%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C23fabd6b67b94e1dc16008d5e0d3d550%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636662122786567530%2526sdata%253DL%25252B3cknwmPbt4rvzFd7sDguzXXNspXHUdnVY4UVIPnW0%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7Cd39e10024e8d42b49b5008d5e106e101%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662342019465396&sdata=m1rx92uuDn17pJHHmDgG19qfv20rMnSqKAkDc6eiv1o%3D&reserved=0
            
            If you have the typedefs changes but not the compiler ones, then 
your Date properties will start coming through as undefined, as it will miss 
the transpiling bit where it converts e.g. "date.day" into "date.getDay()"...
            
            Let me know of any issues (or please add to the discussion comments 
on the pull request instead?)
            
            cheers
            
               Andrew
            
            
            
            -----Original Message-----
            From: Frost, Andrew [mailto:[email protected]] 
            Sent: 02 July 2018 16:53
            To: [email protected]
            Subject: [EXTERNAL] RE: Royale compiler not handling Date.fullYear 
etc
            
            Ah - thank you! Will look at that later and create a pull request 
once everything is in there and testing itself properly..
            
            cheers
            
               Andrew
            
            
            -----Original Message-----
            From: Alex Harui [mailto:[email protected]] 
            Sent: 02 July 2018 16:51
            To: [email protected]
            Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear 
etc
            
            Ah yes, the swfdumps...
            
            So when tests that produce a SWF run without the Flash playerglobal 
and standalone debugger, the test harness runs SWFDump and compares the output. 
 The reference copies of the swfdumps are in 
compiler/src/test/resources/swfdumps and the files have a naming scheme I hope 
you can decode.  So, when you add a new test and it can't find the reference 
swfdump, it will dump what it found to make it easy for you to copy the swfdump 
and make it the reference copy.  So copy the console output of the swfdump and 
create the reference file and it should be ok after that.
            
            Thanks,
            -Alex
            
            On 7/2/18, 8:42 AM, "Frost, Andrew" <[email protected]> wrote:
            
                Latest on this:
                
                With the changes in the compiler per the below suggestion 
(externc-config.xml and ExternCConfiguration changes), we can generate the 
below code (as extracted from js.swc):
                
                        public function get timezoneOffset():Number{
                            return (null);
                        }
                
                And everything looks good... works well, we get the right 
warning out when we try to assign a value to timezoneOffset.
                Changes are visible in 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FyKl3gEt_q3aDsMMXr7J_zEBZYzTBvINHHgxQtZ8QH58%3D%3Fd%3DXVM8wcUx4AVvvnx4aYpF00yk_Eyt9QZZF_c65XW-bGLlOqoBAmP4EZZZHcq3CxBBmKZpgajW8vxVFLmNQUwTkz-h3EmNKlq8UyFiYyklTfyKmivIVAaXa-6Uh22WNmrQPgipIQ5Bl1dYRZXx8v2FZ83ZkYErcY9kwfeFH2td0tJLDs3UuRtInu7Pg3ez7ZpidUYN_NR6xuesnpZ1PdAMKNZA0LhumZmir0NVprDmnsJ1BkaWAy6vXkO3GNuS4KHFrBe1VUQvY5uWuwGnqkMRvZA1N-hVF8cfY4bUQjZbFWjb9oxrU7AbQrtv2GodpVQWdsNUjpiczlfhcvVk8VhPuVjsGma93Tj8zXHuFsMOZxZYg1sTepHUbWoMXGQVGUmK1Jk6EAJ7zyL4lVjxzkNAJ31si4DjoouXLo5Q-D0w0B2oRQ14_ii9MfaNRuJ93qk%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fclicktime.symantec.com%25252Fa%25252F1%25252FwviiW6QxLi8ypSnU5H09X2xjni7YMbYvK77LEkO5CDc%25253D%25253Fd%25253D_zziaDODDuvZwC8YjWYfsPGmQ13A3Q5xBbMSUHKZIo34PLSaC9n5J08tWjYr684YeBkkWxnp2HcZdkgNzuQomI_AxW87-eGOUJ6BX3fpIq_85GevpLOLDtImXR9QSgOqRr8CPPdoqGLktBiwqfyZgvoybKudC2IK3zCmJoehcWoBmeXjp5BYTa2y0nIyvPd5uIG0WYm3JsJ2SYir9Lo6eyi-l_jT5qujCB9duN6TZDMw6d3nk9CU1DUlTgmpu8sTVpksO772_ZC0g-UQ0XAwzNaKvyauEqoa7Dn0h61XfQp5AqHmj6fdgrYEtUrlQQYC5UE3i8HxOcaCgOYGOEQ1GClok3NDQMETE1dyjN20C1N_Z-dWb1-qNMzyGi732Hk-nT_kq4IjD3YDuNeJwtk0wYZ42ik8c4M-nNHDMcZJfnVJf9_MWpQBY7o3JH2Vdg%2525253D%2525253D%252526u%25253Dhttps%2525253A%2525252F%2525252Fna01.safelinks.protection.outlook.com%2525252F%2525253Furl%2525253Dhttps%252525253A%252525252F%252525252Fgithub.com%252525252Fajwfrost%252525252Froyale-compiler%252525252Fcommit%252525252F8157465fbe05022136ae7b405f316e89ee809c97%25252526data%2525253D02%252525257C01%252525257Caharui%2525252540adobe.com%252525257C71b34e8a1cca401a8f6d08d5e032645e%252525257Cfa7b1b5a7b34438794aed2c178decee1%252525257C0%252525257C0%252525257C636661429411013521%25252526sdata%2525253D6DNQpiY0msNOA2%252525252Fj0CiWEvv94X1JfDIacwOlm9nzqqE%252525253D%25252526reserved%2525253D0%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C23fabd6b67b94e1dc16008d5e0d3d550%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636662122786567530%2526sdata%253D6hEzv0grDYsQ3AHulsQ15RkUFlAprJAhN7LDMUXsqso%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7Cd39e10024e8d42b49b5008d5e106e101%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662342019465396&sdata=W2ehZ%2BI95BaCPmRXtYuNdqRAt5JqAoJ%2BBfo4XoiftQc%3D&reserved=0
                but I've not yet created the pull request on this project..
                
                
                In terms of testing: to properly test this, we need to add an 
external test for it (i.e. running through the full compile sequence), so I 
looked at where there are some current tests that do this:
                
royale-compiler\compiler\src\test\java\as\ASExpressionTests.java etc
                and then copy/pasted one of these into a new file 
"ASDateTests.java". However this is causing weird errors: when I build the 
royale-compiler project without this file, I get:
                
                tests:
                    [junit] Running as.ASExpressionTests
                    [junit] looking for 
C:\Work\Royale\royale-compiler\env.properties
                    [junit] environment property - FLEX_HOME = null
                    [junit] environment property - PLAYERGLOBAL_HOME = null
                    [junit] environment property - PLAYERGLOBAL_VERSION = 11.1
                    [junit] environment property - TLF_HOME = null
                    [junit] environment property - AIR_HOME = null
                    [junit] environment property - FLASHPLAYER_DEBUGGER = null
                    [junit] environment property - ASJS_HOME = 
C:\Work\Royale\royale-asjs
                    [junit] environment property - GOOG_HOME = null
                    [junit] Generating test:
                    [junit] Compiling test:
                    [junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests7333543909053470191.as
 
                    [junit] 
                    [junit] 608 bytes written to 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests7333543909053470191.swf
 in 0.817 seconds
                    [junit] After compile:
                    [junit] Unexpected compilation problems:
                    [junit] 
                    [junit] Generating test:
                    [junit] Compiling test:
                    [junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests3291256200729799168.as
 
                    [junit] 
                    [junit] 595 bytes written to 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests3291256200729799168.swf
 in 0.112 seconds
                    [junit] After compile:
                    [junit] Unexpected compilation problems:
                     ... 
                    [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, 
Time elapsed: 1.493 sec
                The "unexpected compilation problems" seem to be 'expected' as 
the result is that the tests all pass..
                
                But when I have a new file ASDateTests.java, I get:
                tests:
                    [junit] Running as.ASDateTests
                    [junit] looking for 
C:\Work\Royale\royale-compiler\env.properties
                    [junit] environment property - FLEX_HOME = null
                    [junit] environment property - PLAYERGLOBAL_HOME = null
                    [junit] environment property - PLAYERGLOBAL_VERSION = 11.1
                    [junit] environment property - TLF_HOME = null
                    [junit] environment property - AIR_HOME = null
                    [junit] environment property - FLASHPLAYER_DEBUGGER = null
                    [junit] environment property - ASJS_HOME = 
C:\Work\Royale\royale-asjs
                    [junit] environment property - GOOG_HOME = null
                    [junit] Generating test:
                    [junit] Compiling test:
                    [junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASDateTests3525997529829206058.as
 
                    [junit] 
                    [junit] 592 bytes written to 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASDateTests3525997529829206058.swf
 in 0.853 seconds
                    [junit] After compile:
                    [junit] Unexpected compilation problems:
                    [junit] 
                    [junit] as_ASDateTests_ASDateTests_simpleTernary_swfdump.xml
                    [junit] <?xml version="1.0" encoding="UTF-8"?>
                    [junit] <!-- Parsing swf 
file:/C:/Work/Royale/royale-compiler/compiler/target/junit-temp/ASDateTests3525997529829206058.swf
 -->
                .. there follows a dump of the SWF contents ...
                    [junit] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, 
Time elapsed: 1.725 sec
                
                
                I'm not sure why it's treating my new file differently from the 
existing ones ... any hints/thoughts?! It seems like all I have to do to 
include these tests is to create this file in the relevant folder, but maybe 
there's another step that I'm missing?
                
                thanks
                
                   Andrew
                
                
                
                
                -----Original Message-----
                From: Frost, Andrew [mailto:[email protected]] 
                Sent: 02 July 2018 10:14
                To: [email protected]
                Subject: [EXTERNAL] RE: Royale compiler not handling 
Date.fullYear etc
                
                Hi
                
                Even if we get the latest version, they still don't support a 
"readonly" annotation:
                
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2F34_ApVH89ZYMA6skDKzoAhaFarF5_Q-YHNeF3Yt77Xs%3D%3Fd%3D_zziaDODDuvZwC8YjWYfsPGmQ13A3Q5xBbMSUHKZIo34PLSaC9n5J08tWjYr684YeBkkWxnp2HcZdkgNzuQomI_AxW87-eGOUJ6BX3fpIq_85GevpLOLDtImXR9QSgOqRr8CPPdoqGLktBiwqfyZgvoybKudC2IK3zCmJoehcWoBmeXjp5BYTa2y0nIyvPd5uIG0WYm3JsJ2SYir9Lo6eyi-l_jT5qujCB9duN6TZDMw6d3nk9CU1DUlTgmpu8sTVpksO772_ZC0g-UQ0XAwzNaKvyauEqoa7Dn0h61XfQp5AqHmj6fdgrYEtUrlQQYC5UE3i8HxOcaCgOYGOEQ1GClok3NDQMETE1dyjN20C1N_Z-dWb1-qNMzyGi732Hk-nT_kq4IjD3YDuNeJwtk0wYZ42ik8c4M-nNHDMcZJfnVJf9_MWpQBY7o3JH2Vdg%253D%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fclicktime.symantec.com%25252Fa%25252F1%25252FT83CUIducqI9Lkpsqh8xgxVIyLMGnJbMonLa5_1_9kg%25253D%25253Fd%25253Da9uxnQqkSmG7oTXapoG51ZcBcs2YQHVAyX7jtig52n_nvBCIyavSa7KScNwp1Pl-KHVyOVX10_IT-KhaR3dogyBF_PhM8l3mUniTusdETZeur68fGw663Yj8q73kuaKvNSfxQjwF-6v9sicptU6c945r2TlZu66048QF9Hc5OfDqAjf3LVZb5gbp2xebFV7gzThYfrj1WT851Sp6LaTuiiQKrNJnk-b2P2hiwTctWCrxALua42IS-8UJgp9t515EbpW7BWVMaS7827cZqn5K1H5bcXQ2kYGEL8HrJLm5nnsDgC9IpTYdOcwHuxR3TmYpp6ymdh14dZ6Mc2O9_fpD1E9WaZW9n2sYlFHXAMQFYuvNMQeXTSETZlJ0B0fYtPOnVyR-jL7hXo3MptfdPzl3nzfuVaJFJaVoPEXU5m8yhCn-2McWhLwPf0UNxPbmL58COzo4KqYtEqA%2525253D%252526u%25253Dhttps%2525253A%2525252F%2525252Fgithub.com%2525252Fgoogle%2525252Fclosure-compiler%2525252Fblob%2525252Fmaster%2525252Fsrc%2525252Fcom%2525252Fgoogle%2525252Fjavascript%2525252Fjscomp%2525252Fparsing%2525252FAnnotation.java%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C71b34e8a1cca401a8f6d08d5e032645e%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636661429411023530%2526sdata%253D5QX90Py%25252BYSblXW%25252BRjKw4q9IouS9O6QYCuXN%25252FcndrJ00%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530&sdata=hEl0rpHLA%2Bq9TVOnEXt8nybUN7z9xAMMnwbmssQzYZU%3D&reserved=0
                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 ExternCConfiguration.java 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...
                
                cheers
                
                   Andrew
                
                
                
                -----Original Message-----
                From: Alex Harui [mailto:[email protected]] 
                Sent: 30 June 2018 08:00
                To: [email protected]
                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:  
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FQUWhsoxKtWnoa75S5qhiHUOQqaPDxNbZ7aRKeLE1_2U%3D%3Fd%3D_zziaDODDuvZwC8YjWYfsPGmQ13A3Q5xBbMSUHKZIo34PLSaC9n5J08tWjYr684YeBkkWxnp2HcZdkgNzuQomI_AxW87-eGOUJ6BX3fpIq_85GevpLOLDtImXR9QSgOqRr8CPPdoqGLktBiwqfyZgvoybKudC2IK3zCmJoehcWoBmeXjp5BYTa2y0nIyvPd5uIG0WYm3JsJ2SYir9Lo6eyi-l_jT5qujCB9duN6TZDMw6d3nk9CU1DUlTgmpu8sTVpksO772_ZC0g-UQ0XAwzNaKvyauEqoa7Dn0h61XfQp5AqHmj6fdgrYEtUrlQQYC5UE3i8HxOcaCgOYGOEQ1GClok3NDQMETE1dyjN20C1N_Z-dWb1-qNMzyGi732Hk-nT_kq4IjD3YDuNeJwtk0wYZ42ik8c4M-nNHDMcZJfnVJf9_MWpQBY7o3JH2Vdg%253D%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fclicktime.symantec.com%25252Fa%25252F1%25252Ft8Vt55bBn1paDRrO_tcbGDw3nOt-4_f5sEQDRaUr78g%25253D%25253Fd%25253DlhuiLMs5TaNvmSSfvLo9lH6b9M276TThXO9G60OlPgOsY0f-pENIrkec8khCn7viL4JfEe1fvVJVaiQjQh6BhiYP7C_O9RJunWasASxHmucjtZZQBzeCviGxf9lrMUs0zxkkPNHBoa_rq8QP8-dOSlYcneP9T5WOgjLYBeKsizspqFWxP5Szt6O6GYS1QKNQtcPvwoh5NSOLYeB2K3j46FeJyZfM51xmX1vX4JN5xKWd1bY4mOAK6B9Kr7A2u6i65r0iSYuzL8ok9ybJXKGK43QxR_nahrgFSKD2Bg-0iMujUKi8uNlZ5kOGSzi3oE0ByPCbF-4QIZtYTa3V7zQ1AaG4rQnICykl0p0UohbhZZrVdA2536sB_xwCGEKvHXA0Hf5_evEzsPHoxiB5HeyKiYQW8vzNmmT3CSqOKfakgQLVd_4l5xMYQ7AeYmU%2525253D%252526u%25253Dhttps%2525253A%2525252F%2525252Fgithub.com%2525252Fgoogle%2525252Fclosure-compiler%2525252Fissues%2525252F139%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C71b34e8a1cca401a8f6d08d5e032645e%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636661429411023530%2526sdata%253D8%25252F%25252FVIPCYKVmYbNzmsKLIWPe3pj9aLtL2ZLJvW9fEvDc%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530&sdata=eeaOYqkTqPAoWQVvGcPgvCs8Ldw0xt2hJXpYkUQEzs0%3D&reserved=0
                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.
                
                HTH,
                -Alex
                
                On 6/29/18, 11:46 PM, "Frost, Andrew" <[email protected]> 
wrote:
                
                    Hi
                    
                    Well @const is at least supported by the Google classes; 
with a slight change in FieldReference.java 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 hack!
                    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 source!
                    
                    
                    thanks
                    
                       Andrew
                    
                    
                    
                    -----Original Message-----
                    From: Alex Harui [mailto:[email protected]] 
                    Sent: 30 June 2018 07:19
                    To: [email protected]
                    Subject: [EXTERNAL] Re: Royale compiler not handling 
Date.fullYear etc
                    
                    Interesting.  In 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FJu25ASzndEjOnqYNDd7xiVeQME8ALGuo-URR6C3y6WI%3D%3Fd%3DlhuiLMs5TaNvmSSfvLo9lH6b9M276TThXO9G60OlPgOsY0f-pENIrkec8khCn7viL4JfEe1fvVJVaiQjQh6BhiYP7C_O9RJunWasASxHmucjtZZQBzeCviGxf9lrMUs0zxkkPNHBoa_rq8QP8-dOSlYcneP9T5WOgjLYBeKsizspqFWxP5Szt6O6GYS1QKNQtcPvwoh5NSOLYeB2K3j46FeJyZfM51xmX1vX4JN5xKWd1bY4mOAK6B9Kr7A2u6i65r0iSYuzL8ok9ybJXKGK43QxR_nahrgFSKD2Bg-0iMujUKi8uNlZ5kOGSzi3oE0ByPCbF-4QIZtYTa3V7zQ1AaG4rQnICykl0p0UohbhZZrVdA2536sB_xwCGEKvHXA0Hf5_evEzsPHoxiB5HeyKiYQW8vzNmmT3CSqOKfakgQLVd_4l5xMYQ7AeYmU%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fclicktime.symantec.com%25252Fa%25252F1%25252FuntftVdsWwPmiJWAVt3nm3wg6v4ZACZ9RDBNQjuszM0%25253D%25253Fd%25253DbbejT-O_-jFYytoEIpecgb-HW7JAfVy-JYJKJjpirj9WyJta8y-Vetrzg91hMyjxwIZDBbGoPRETuW8R-_GJ2QI3JFRNDooGe4nnEJmgsbOCgX9zvdpNOtRejsS_vQ96JFtVBei96NlGXnAeb9O-n2UPHrthFwLfNhxhivyLhutMuYZf1_Bwf9uhuogWi4XEGnREN0VeGK-7HR-0IXBlFkwvMeyJ_r7KS89xbvNmYhN1EFExUVrPWOSGUU7bDbqQGwx_iQnLVTX8Lj1IsNPJvd8qUgJnR5R6P-smt5q_FBaLNjsRWDWI0U_XMUyRIY_5-Kz1H2BKLxZppDcoEdbSVn_k9bD-Eo7722e3Jajt9nKt5EOvpU8kzNvIgbQxRNW4JbQ0gyaaZG-838aZUMmtuoW39NTiDdhoowZejUVmDmKstEs8NbBBtOnE3Ck%2525253D%252526u%25253Dhttps%2525253A%2525252F%2525252Fgithub.com%2525252Fgoogle%2525252Fclosure-compiler%2525252Fwiki%2525252FAnnotating-JavaScript-for-the-Closure-Compiler%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257Cb7acdaa31fda47dff0c508d5de553e2e%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C1%25257C636659380078411962%2526sdata%253DoCQLuHrDHlf9BSbfTC%25252F2UJgSlMLkKV2kNQ0z3FX%25252F%25252Bxk%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7C71b34e8a1cca401a8f6d08d5e032645e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636661429411023530&sdata=lqXDq0EMQ9xVe%2FcLOKXLzlRIMfxI%2BAUaBo7H7FWLMQM%3D&reserved=0
 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.
                    
                    HTH,
                    -Alex
                    
                    On 6/29/18, 3:55 PM, "Frost, Andrew" 
<[email protected]> wrote:
                    
                        Hi
                        
                        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:
                        royale-compiler/compiler/src/test/java/as
                        
                        In terms of the read-only properties, I would have 
hoped that the definition in missing.js could be written:
                        /**
                         * @type {number}
                         * @property
                         * @readonly
                         */
                        Date.prototype.timezoneOffset;
                        
                        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 FieldReference.java 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?
                        royale-typedefs\js\src\main\javascript\missing.js
                        
royale-compiler\compiler-externc\src\test\resources\typedefs\unit_tests\missing.js
                        
                        
                        thanks
                        
                           Andrew
                        
                        
                        
                        -----Original Message-----
                        From: Alex Harui [mailto:[email protected]] 
                        Sent: 29 June 2018 17:38
                        To: [email protected]
                        Subject: [EXTERNAL] Re: Royale compiler not handling 
Date.fullYear etc
                        
                        There are Date tests in TestRoyaleGlobalClasses.java
                        
                        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,
                        -Alex
                        
                        On 6/29/18, 7:47 AM, "Frost, Andrew" 
<[email protected]> 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 :-)
                            
                            thanks
                            
                               Andrew
                            
                            
                            -----Original Message-----
                            From: Harbs [mailto:[email protected]] 
                            Sent: 29 June 2018 13:35
                            To: [email protected]
                            Subject: [EXTERNAL] Re: Royale compiler not 
handling Date.fullYear etc
                            
                            Cool. Are there compiler tests for these Date 
additions?
                            
                            
                        
                        
                    
                    
                
                
            
            
        
        
    
    

Reply via email to