royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: Royale compiler not handling Date.fullYear etc
Date Fri, 29 Jun 2018 12:34:30 GMT
Cool. Are there compiler tests for these Date additions?

> On Jun 29, 2018, at 3:03 PM, Frost, Andrew <Andrew.Frost@Harman.com> 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:aharui@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.lists@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.Frost@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.Frost@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.lists@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 <aharui@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.
>> 
> 
> 
> 


Mime
View raw message