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://clicktime.symantec.com/a/1/untftVdsWwPmiJWAVt3nm3wg6v4ZACZ9RDBNQjuszM0=?d=bbejT-O_-jFYytoEIpecgb-HW7JAfVy-JYJKJjpirj9WyJta8y-Vetrzg91hMyjxwIZDBbGoPRETuW8R-_GJ2QI3JFRNDooGe4nnEJmgsbOCgX9zvdpNOtRejsS_vQ96JFtVBei96NlGXnAeb9O-n2UPHrthFwLfNhxhivyLhutMuYZf1_Bwf9uhuogWi4XEGnREN0VeGK-7HR-0IXBlFkwvMeyJ_r7KS89xbvNmYhN1EFExUVrPWOSGUU7bDbqQGwx_iQnLVTX8Lj1IsNPJvd8qUgJnR5R6P-smt5q_FBaLNjsRWDWI0U_XMUyRIY_5-Kz1H2BKLxZppDcoEdbSVn_k9bD-Eo7722e3Jajt9nKt5EOvpU8kzNvIgbQxRNW4JbQ0gyaaZG-838aZUMmtuoW39NTiDdhoowZejUVmDmKstEs8NbBBtOnE3Ck%3D&u=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler
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?
