Yes - it needed changes both in the typedefs and in the compiler; and also, this is just to workaround the syntax checking part, as the conversion that was already present will now kick in..
Did a few tests on it and noticed that I could assign to the timezoneOffset [read-only] property, although nothing actually happened when I did so. So I've added a check for this one, it feels a bit manual/hacky but I don't know of any alternative approach.. Pull requests just created on the typedefs and the compiler projects; they should really be taken together otherwise it could get problematic! thanks Andrew -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com.INVALID] Sent: 28 June 2018 22:17 To: dev@royale.apache.org Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc I think Andrew got it right, but I believe he is still adding fullYear and others to Date in missing.js. It is ok for us to add APIs that exist in Flash that don't exist in the browser if we map them to browser APIs that do exist. In this case, the browser's Date.getFullYear/setFullYear. No polyfill is needed. We have done this sort of thing for other mismatches between Flash and the browser. It is smaller/faster to handle these known builtin APIs in the compiler than to create polyfills for them when we can. But Language does contain some polyfills for Array. The reason Andrew had to add the lines he did is because in externs/typedefs like missing.js, the only way to specify an Accessor (a getter/setter) is by having a corresponding definition in an interface in the externs. Date doesn't implement any interfaces, so the definition ends up as a Variable (a var). The code for isDateProperty was expecting the Flash definition of Date which does have fullYear and all other properties as Accessor. I think it was reasonable to allow Variables as well. Andrew, if you can package up your changes as patches or pull requests, that would be great. I probably won't be able to get to it until Sunday, but maybe someone else will accept your changes. Thanks, -Alex On 6/28/18, 12:14 PM, "Harbs" <harbs.li...@gmail.com> wrote: It sounds like you’re right and adding it to the Date definitions in missing.js is not the right way to go about it. That assumes it’s defined in the browser which it’s not… The only way that would work would be to polypill the global Date object which we don’t want to do. I’m guessing something along the lines of your original suggestion is the right way to go about it, but I’m definitely not an expert on the compiler. Thanks, Harbs > On Jun 28, 2018, at 10:07 PM, Frost, Andrew <andrew.fr...@harman.com> wrote: > > Okay here's the conclusion: > > JSRoyaleEmitter.isDateProperty() is returning false now, because we do actually have a definition for the property name (rightDef is no longer null, so we don't go into the next check..). > > isDateProperty() is called from three places (BinaryOperatorEmitter, MemberAccessEmitter, VarDeclarationEmitter) but then where necessary it uses the actual DatePropertiesSetters/Getters lists to convert the output. > > Given that we don't have any other properties on the Date object, it should be feasible to add an extra condition under the "rightDef instanceof AccessorDefinition", to also check "rightDef instanceof VariableDefinition" and return true (unless people think we should also go through the DatePropertiesSetters/Getters lists to double-check that it's a property that can be converted?) > > This now works: so with the changes to the missing.js, we also have: > if (leftDef != null && leftDef.getQualifiedName().equals("Date")) > { > if (rightDef instanceof AccessorDefinition) > return true; > + else if (rightDef instanceof VariableDefinition) > + return true; > else if (rightDef == null && rightNode.getNodeID() == ASTNodeID.IdentifierID) > { > if (writeAccess) > { > > and it works... > > > > thanks > > Andrew > > > -----Original Message----- > From: Frost, Andrew [mailto:andrew.fr...@harman.com] > Sent: 28 June 2018 19:37 > To: dev@royale.apache.org > Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc > > Hi > > Thanks Alex for the explanation and background! Yes I think that the BinaryOperatorEmitter code is kicking in to do the actual conversion during the emitting phase, so that bit works fine; it was just earlier on (and as you suggest, a think it's trying to build some ABC from the parsed tree which is where this issue came up - ASCompilationUnit.handleABCBytesRequest is lower down the call stack..) > > I hadn't spotted the 'missing.js' file; presumably then, this is compiled into the js.swc file ... > > First try: I just added the blank definition "Date.prototype.fullYear;" to the bottom of missing.js per Harbs' suggestion, and built js.swc again (had to manually then copy it into the royale-asjs folder?); this solved the compilation error but then I think the later conversion to getFullYear() didn't work as this returned "undefined" when I called it... > > Second try: adding the below to missing.js: > Date.prototype.__defineGetter__("fullYear", function() { return this.getFullYear(); }); just didn't work; the generated SWC file didn't include any properties on the Date object. > > I've tried a couple of other things but I'm not sure how it would be possible to add separate get/set methods using this mechanism.. or maybe the translation needs to change so that it has higher priority? > > I'll do a little more digging, unless anyone knows how we could map different functions to the set/get methods? Maybe with the below updates, it makes more sense to change the specialCaseDate function.. > > thanks > > Andrew > > > -----Original Message----- > From: Harbs [mailto:harbs.li...@gmail.com] > Sent: 28 June 2018 19:31 > To: dev@royale.apache.org > Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc > > Yes. That sounds like a good solution to me. > > Adding: > /** > * @type {number} > */ > Date.prototype.time; > > /** > * @type {number} > */ > Date.prototype.fullYear; > > Etc… to missing.js should do it. > > Harbs > >> On Jun 28, 2018, at 8:36 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> It's only been the past year or so that we've got the "JS Only" configuration working where you compile against js.swc instead of playerglobal. And I suspect that nobody has tried Date until you just did. We could say that, if you are compiling against js.swc you are expected to use the APIs for the browser and can't use Date.fullYear, but because specialCaseDate already exists, we have the choice of adding Date.fullYear to the missing.js file in royale-typedefs/js/src/main/javascript. Then I think you would be allowed to use Date.fullYear and it would get transpiled correctly. >> >> I don't see any harm in adding SWF APIs to js.swc if we know how to transpile them. What do others think? It would be great if you could give that a try. >
