Re: New (optional) AS3 compiler feature: Type inference

[Josh Tynjala]

I think it would be feasible for vscode-as3mxml to provide a quick fix to
convert the inferred type into an explicitly declared type, if that's what
you mean. I don't think that there's any other tool where it makes sense.
The formatter, for instance, can see the type declarations, but it doesn't
understand the types.

Yes, assigning the variable when it is declared is required (but it doesn't
need to be a literal value... another variable, or even a more complex
expression with operators, function calls, etc. can have their types
detected by the compiler). With no declared type and no assignment, the
variable's value defaults to undefined, which would be inferred as type *
instead.

--
Josh Tynjala
Bowler Hat LLC 


On Tue, Jun 20, 2023 at 2:23 PM Harbs  wrote:

> Nice.
>
> I personally like explicit types because it’s more human readable.
>
> How feasable would it be to automatically add types to the code based on
> type inference. So var s = “hello” could be transformed to var s:String =
> “hello”.
>
> Do you need to assign the variable when it’s declared for this to work?
>
> > On Jun 21, 2023, at 12:07 AM, Josh Tynjala 
> wrote:
> >
> > Hi all,
> >
> > One cool feature in other languages similar to AS3, such as TypeScript or
> > Haxe, is type inference. It allows developers to optionally omit a type
> > declaration from a variable, or a function signature, by having the
> > compiler automatically detect an appropriate type from context.
> >
> > For example, you traditionally would declare a variable with a String
> type
> > like this:
> >
> > var s:String = "hello";
> >
> > If you enable type inference, you can declare the same variable like this
> > instead because the compiler knows that the initializer is a string.
> >
> > var s = "hello";
> >
> > Type inference applies to local/member/static variables, getters/setters,
> > function parameters, and function return values. If a function has
> multiple
> > return statements, the type inference will try to find a common base
> type,
> > if possible. If a type cannot be inferred for any reason, the compiler
> will
> > fall back to the * type, and you'll get a warning, the same as when type
> > inference is disabled.
> >
> > If you build the compiler from source (or download the next nightly
> build),
> > you can enable this feature in your project using the new
> -infer-types=true
> > compiler option. It is opt-in for now, to avoid any potential backwards
> > compatibility issues with existing code.
> >
> > I also wrote some documentation with examples and more detailed
> > explanations:
> >
> > https://apache.github.io/royale-docs/features/as3/type-inference
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC 
>
>

Re: New (optional) AS3 compiler feature: Type inference

[Harbs]

Nice.

I personally like explicit types because it’s more human readable.

How feasable would it be to automatically add types to the code based on type 
inference. So var s = “hello” could be transformed to var s:String = “hello”.

Do you need to assign the variable when it’s declared for this to work?

> On Jun 21, 2023, at 12:07 AM, Josh Tynjala  wrote:
> 
> Hi all,
> 
> One cool feature in other languages similar to AS3, such as TypeScript or
> Haxe, is type inference. It allows developers to optionally omit a type
> declaration from a variable, or a function signature, by having the
> compiler automatically detect an appropriate type from context.
> 
> For example, you traditionally would declare a variable with a String type
> like this:
> 
> var s:String = "hello";
> 
> If you enable type inference, you can declare the same variable like this
> instead because the compiler knows that the initializer is a string.
> 
> var s = "hello";
> 
> Type inference applies to local/member/static variables, getters/setters,
> function parameters, and function return values. If a function has multiple
> return statements, the type inference will try to find a common base type,
> if possible. If a type cannot be inferred for any reason, the compiler will
> fall back to the * type, and you'll get a warning, the same as when type
> inference is disabled.
> 
> If you build the compiler from source (or download the next nightly build),
> you can enable this feature in your project using the new -infer-types=true
> compiler option. It is opt-in for now, to avoid any potential backwards
> compatibility issues with existing code.
> 
> I also wrote some documentation with examples and more detailed
> explanations:
> 
> https://apache.github.io/royale-docs/features/as3/type-inference
> 
> --
> Josh Tynjala
> Bowler Hat LLC 

New (optional) AS3 compiler feature: Type inference

[Josh Tynjala]

Hi all,

One cool feature in other languages similar to AS3, such as TypeScript or
Haxe, is type inference. It allows developers to optionally omit a type
declaration from a variable, or a function signature, by having the
compiler automatically detect an appropriate type from context.

For example, you traditionally would declare a variable with a String type
like this:

var s:String = "hello";

If you enable type inference, you can declare the same variable like this
instead because the compiler knows that the initializer is a string.

var s = "hello";

Type inference applies to local/member/static variables, getters/setters,
function parameters, and function return values. If a function has multiple
return statements, the type inference will try to find a common base type,
if possible. If a type cannot be inferred for any reason, the compiler will
fall back to the * type, and you'll get a warning, the same as when type
inference is disabled.

If you build the compiler from source (or download the next nightly build),
you can enable this feature in your project using the new -infer-types=true
compiler option. It is opt-in for now, to avoid any potential backwards
compatibility issues with existing code.

I also wrote some documentation with examples and more detailed
explanations:

https://apache.github.io/royale-docs/features/as3/type-inference

--
Josh Tynjala
Bowler Hat LLC 

Re: Adding Royale Compiler to reproducible-central

[Josh Tynjala]

Yes, I assume that it's because they didn't use option-with-swf, but
they're comparing to a version that did.

I don't really know why sources JARs are uploaded, or whether they're
supposed to be reproducible or not.

--
Josh Tynjala
Bowler Hat LLC 


On Sun, Jun 18, 2023 at 1:25 AM Yishay Weiss  wrote:

> >1) It looks like they built without playerglobal.swc, but they are
> comparing to a build that used playerglobal.swc
>
> Is that because they didn't use the option-with-swf option?
>
> >2) The emitHeader() method in JBurgGenerator adds the current date to a
> comment:
>
> I looked at the validation script in compiler/releasesteps.xml and it
> looks like there is no comparison of sources.jar, which is what they tested
> for (namely compiler-0.9.10-sources.jar). Only binary jars get validated.
>
> Are *sources jars uploaded solely for debugging convenience? If so, can we
> say that those should not be tested for reproducibility?
>
>
> 
> From: Josh Tynjala 
> Sent: Thursday, June 15, 2023 7:13 PM
> To: dev@royale.apache.org 
> Subject: Re: Adding Royale Compiler to reproducible-central
>
> A couple of obvious things that I see right away:
>
> 1) It looks like they built without playerglobal.swc, but they are
> comparing to a build that used playerglobal.swc.
>
> 2) The emitHeader() method in JBurgGenerator adds the current date to a
> comment:
>
>
> https://github.com/apache/royale-compiler/blob/apache-royale-0.9.10/compiler-jburg-types/src/main/java/jburg/burg/JBurgGenerator.java#L1048-L1053
>
> To make it reproducible, this should either use a fixed date passed in as
> part of the build, or the generated comment shouldn't include the date at
> all.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Thu, Jun 15, 2023 at 12:31 AM Yishay Weiss 
> wrote:
>
> > Hi,
> >
> > There's been a lot of talk recently on ASF's members channel regarding
> > reproducible builds, which has brought me to this repo [1] which lists
> > known reproducible artifacts. I've opened a ticket [2] requesting our
> > compiler be added and have received a report of some differences in
> > binaries.
> >
> > Does anyone want to take a look?
> >
> > Thanks,
> > Yishay
> >
> > [1] jvm-repo-rebuild/reproducible-central: Reproducible Central: rebuild
> > instructions for artifacts published to (Maven) Central Repository (
> > github.com)
> > [2] Add org.apache.royale · Issue #117 ·
> > jvm-repo-rebuild/reproducible-central (github.com)<
> > https://github.com/jvm-repo-rebuild/reproducible-central/issues/117>
> >
>