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 <[email protected]> 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:[email protected]] > Sent: 28 June 2018 19:37 > To: [email protected] > 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:[email protected]] > Sent: 28 June 2018 19:31 > To: [email protected] > 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 <[email protected]> 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. >
