Cool. Are there compiler tests for these Date additions?
> On Jun 29, 2018, at 3:03 PM, Frost, Andrew <[email protected]> wrote:
>
> 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:[email protected]]
> Sent: 28 June 2018 22:17
> To: [email protected]
> 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" <[email protected]> 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 <[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.
>>
>
>
>
