Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Harbs
One suggestion on this:

Instead of making it a simple true/false, I’d suggest a tristate control of true/false/booleans.

The reason I’m making that suggestion is because even without strict equality, setting booleans to false has the benefit that bool1 == bool2 will work as expected where undefined might not.

FWIW, I have discovered that undefined for Numbers generally behaves the same as NaN. I have also discovered that it’s very useful to NOT initialize Numbers. Most NaN math errors I get are due to math with numbers which have not been properly initialized. Anytime I get an unexpected NaN value, I’ve found it’s very easy to walk up the stack trace to discover where math has been done with an undefined value which basically without fail exposes the bug. Initializing the values to NaN would mask the issues and make them harder to find.

My $0.02,
Harbs

> On Aug 1, 2017, at 1:02 AM, [hidden email] wrote:
>
> Repository: flex-falcon
> Updated Branches:
>  refs/heads/develop b04074bf0 -> c500b3fe5
>
>
> compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.
>
> -js-default-initializers defaults to false and is completely optional, but may be useful for porting SWF projects to JS if an existing codebase uses strict equality and relies on the SWF default initializers.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-falcon/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-falcon/commit/c500b3fe
> Tree: http://git-wip-us.apache.org/repos/asf/flex-falcon/tree/c500b3fe
> Diff: http://git-wip-us.apache.org/repos/asf/flex-falcon/diff/c500b3fe
>
> Branch: refs/heads/develop
> Commit: c500b3fe52299272dbf201033723296057c79413
> Parents: b04074b
> Author: Josh Tynjala <[hidden email]>
> Authored: Mon Jul 31 14:47:24 2017 -0700
> Committer: Josh Tynjala <[hidden email]>
> Committed: Mon Jul 31 14:54:24 2017 -0700
>
> ----------------------------------------------------------------------
> .../flex/compiler/clients/JSConfiguration.java  | 19 ++++++
> .../codegen/js/jx/VarDeclarationEmitter.java    | 61 ++++++++++++++++----
> 2 files changed, 68 insertions(+), 12 deletions(-)
> ----------------------------------------------------------------------
>
>
> http://git-wip-us.apache.org/repos/asf/flex-falcon/blob/c500b3fe/compiler-jx/src/main/java/org/apache/flex/compiler/clients/JSConfiguration.java
> ----------------------------------------------------------------------
> diff --git a/compiler-jx/src/main/java/org/apache/flex/compiler/clients/JSConfiguration.java b/compiler-jx/src/main/java/org/apache/flex/compiler/clients/JSConfiguration.java
> index ab1c73c..9f6bbe9 100644
> --- a/compiler-jx/src/main/java/org/apache/flex/compiler/clients/JSConfiguration.java
> +++ b/compiler-jx/src/main/java/org/apache/flex/compiler/clients/JSConfiguration.java
> @@ -118,6 +118,25 @@ public class JSConfiguration extends Configuration
>     }
>
>     //
> +    // 'js-default-initializers'
> +    //
> +
> +    private boolean jsDefaultInitializers = false;
> +
> +    public boolean getJsDefaultInitializers()
> +    {
> +        return jsDefaultInitializers;
> +    }
> +
> +    @Config
> +    @Mapping("js-default-initializers")
> +    public void setJsDefaultInitializers(ConfigurationValue cv, boolean value)
> +            throws ConfigurationException
> +    {
> +        jsDefaultInitializers = value;
> +    }
> +
> +    //
>     // 'compiler.js-external-library-path' option
>     //
>
>
> http://git-wip-us.apache.org/repos/asf/flex-falcon/blob/c500b3fe/compiler-jx/src/main/java/org/apache/flex/compiler/internal/codegen/js/jx/VarDeclarationEmitter.java
> ----------------------------------------------------------------------
> diff --git a/compiler-jx/src/main/java/org/apache/flex/compiler/internal/codegen/js/jx/VarDeclarationEmitter.java b/compiler-jx/src/main/java/org/apache/flex/compiler/internal/codegen/js/jx/VarDeclarationEmitter.java
> index 4e35e39..e71c54e 100644
> --- a/compiler-jx/src/main/java/org/apache/flex/compiler/internal/codegen/js/jx/VarDeclarationEmitter.java
> +++ b/compiler-jx/src/main/java/org/apache/flex/compiler/internal/codegen/js/jx/VarDeclarationEmitter.java
> @@ -21,6 +21,7 @@ package org.apache.flex.compiler.internal.codegen.js.jx;
>
> import org.apache.flex.compiler.codegen.ISubEmitter;
> import org.apache.flex.compiler.codegen.js.IJSEmitter;
> +import org.apache.flex.compiler.constants.IASKeywordConstants;
> import org.apache.flex.compiler.constants.IASLanguageConstants;
> import org.apache.flex.compiler.definitions.IDefinition;
> import org.apache.flex.compiler.definitions.metadata.IMetaTag;
> @@ -28,11 +29,13 @@ import org.apache.flex.compiler.definitions.metadata.IMetaTagAttribute;
> import org.apache.flex.compiler.internal.codegen.as.ASEmitterTokens;
> import org.apache.flex.compiler.internal.codegen.js.JSSubEmitter;
> import org.apache.flex.compiler.internal.codegen.js.flexjs.JSFlexJSEmitter;
> +import org.apache.flex.compiler.internal.projects.FlexJSProject;
> import org.apache.flex.compiler.internal.tree.as.ChainedVariableNode;
> import org.apache.flex.compiler.internal.tree.as.DynamicAccessNode;
> import org.apache.flex.compiler.internal.tree.as.FunctionCallNode;
> import org.apache.flex.compiler.internal.tree.as.IdentifierNode;
> import org.apache.flex.compiler.internal.tree.as.MemberAccessExpressionNode;
> +import org.apache.flex.compiler.projects.ICompilerProject;
> import org.apache.flex.compiler.tree.ASTNodeID;
> import org.apache.flex.compiler.tree.as.IASNode;
> import org.apache.flex.compiler.tree.as.IEmbedNode;
> @@ -182,18 +185,52 @@ public class VarDeclarationEmitter extends JSSubEmitter implements
>                 typedef = enode.resolveType(getWalker().getProject());
>             if (typedef != null)
>             {
> -        String defName = typedef.getQualifiedName();
> -        if (defName.equals("int") || defName.equals("uint"))
> -        {
> -         if (node.getParent() != null &&
> -         node.getParent().getParent() != null &&
> -         node.getParent().getParent().getNodeID() != ASTNodeID.Op_InID)
> -         {
> -            write(ASEmitterTokens.SPACE);
> -            writeToken(ASEmitterTokens.EQUAL);
> -            write("0");
> -         }
> -        }
> +                boolean defaultInitializers = false;
> +                ICompilerProject project = getProject();
> +                if(project instanceof FlexJSProject)
> +                {
> +                    FlexJSProject fjsProject = (FlexJSProject) project;
> +                    if(fjsProject.config != null)
> +                    {
> +                        defaultInitializers = fjsProject.config.getJsDefaultInitializers();
> +                    }
> +                }
> +                if (node.getParent() != null &&
> +                        node.getParent().getParent() != null &&
> +                        node.getParent().getParent().getNodeID() != ASTNodeID.Op_InID)
> +                {
> +                    String defName = typedef.getQualifiedName();
> +                    if (defName.equals("int") || defName.equals("uint"))
> +                    {
> +                        write(ASEmitterTokens.SPACE);
> +                        writeToken(ASEmitterTokens.EQUAL);
> +                        write("0");
> +                    }
> +                    if (defaultInitializers)
> +                    {
> +                        if (defName.equals("Number"))
> +                        {
> +                            write(ASEmitterTokens.SPACE);
> +                            writeToken(ASEmitterTokens.EQUAL);
> +                            write(IASKeywordConstants.NA_N);
> +                        }
> +                        else if (defName.equals("Boolean"))
> +                        {
> +                            write(ASEmitterTokens.SPACE);
> +                            writeToken(ASEmitterTokens.EQUAL);
> +                            write(IASKeywordConstants.FALSE);
> +                        }
> +                        else if (!defName.equals("*"))
> +                        {
> +                            //type * is meant to default to undefined, so it
> +                            //doesn't need to be initialized, but everything
> +                            //else should default to null
> +                            write(ASEmitterTokens.SPACE);
> +                            writeToken(ASEmitterTokens.EQUAL);
> +                            write(IASKeywordConstants.NULL);
> +                        }
> +                    }
> +                }
>             }
>         }
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Josh Tynjala
I think if booleans could fail even non-strict equality checks when they
are not initialized, then we should always initialize booleans, like we
currently do with int and uint. It doesn't even make sense to make it an
option for booleans, if that's the case. It's just broken.

I would still like the see the compiler initialize everything by default so
that ActionScript behaves like ActionScript. I think we're making a mistake
by making non-initialization the default. Maybe I'll convince others
eventually.

- Josh

On Tue, Aug 1, 2017 at 11:09 AM, Harbs <[hidden email]> wrote:

> One suggestion on this:
>
> Instead of making it a simple true/false, I’d suggest a tristate control
> of true/false/booleans.
>
> The reason I’m making that suggestion is because even without strict
> equality, setting booleans to false has the benefit that bool1 == bool2
> will work as expected where undefined might not.
>
> FWIW, I have discovered that undefined for Numbers generally behaves the
> same as NaN. I have also discovered that it’s very useful to NOT initialize
> Numbers. Most NaN math errors I get are due to math with numbers which have
> not been properly initialized. Anytime I get an unexpected NaN value, I’ve
> found it’s very easy to walk up the stack trace to discover where math has
> been done with an undefined value which basically without fail exposes the
> bug. Initializing the values to NaN would mask the issues and make them
> harder to find.
>
> My $0.02,
> Harbs
>
> > On Aug 1, 2017, at 1:02 AM, [hidden email] wrote:
> >
> > Repository: flex-falcon
> > Updated Branches:
> >  refs/heads/develop b04074bf0 -> c500b3fe5
> >
> >
> > compiler-jx: Added -js-default-initializers option to force
> uninitialized variables to default to the same values in JS as they do in
> SWF.
> >
> > -js-default-initializers defaults to false and is completely optional,
> but may be useful for porting SWF projects to JS if an existing codebase
> uses strict equality and relies on the SWF default initializers.
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/flex-falcon/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/flex-falcon/commit/
> c500b3fe
> > Tree: http://git-wip-us.apache.org/repos/asf/flex-falcon/tree/c500b3fe
> > Diff: http://git-wip-us.apache.org/repos/asf/flex-falcon/diff/c500b3fe
> >
> > Branch: refs/heads/develop
> > Commit: c500b3fe52299272dbf201033723296057c79413
> > Parents: b04074b
> > Author: Josh Tynjala <[hidden email]>
> > Authored: Mon Jul 31 14:47:24 2017 -0700
> > Committer: Josh Tynjala <[hidden email]>
> > Committed: Mon Jul 31 14:54:24 2017 -0700
> >
> > ----------------------------------------------------------------------
> > .../flex/compiler/clients/JSConfiguration.java  | 19 ++++++
> > .../codegen/js/jx/VarDeclarationEmitter.java    | 61
> ++++++++++++++++----
> > 2 files changed, 68 insertions(+), 12 deletions(-)
> > ----------------------------------------------------------------------
> >
> >
> > http://git-wip-us.apache.org/repos/asf/flex-falcon/blob/
> c500b3fe/compiler-jx/src/main/java/org/apache/flex/compiler/
> clients/JSConfiguration.java
> > ----------------------------------------------------------------------
> > diff --git a/compiler-jx/src/main/java/org/apache/flex/compiler/clients/JSConfiguration.java
> b/compiler-jx/src/main/java/org/apache/flex/compiler/
> clients/JSConfiguration.java
> > index ab1c73c..9f6bbe9 100644
> > --- a/compiler-jx/src/main/java/org/apache/flex/compiler/
> clients/JSConfiguration.java
> > +++ b/compiler-jx/src/main/java/org/apache/flex/compiler/
> clients/JSConfiguration.java
> > @@ -118,6 +118,25 @@ public class JSConfiguration extends Configuration
> >     }
> >
> >     //
> > +    // 'js-default-initializers'
> > +    //
> > +
> > +    private boolean jsDefaultInitializers = false;
> > +
> > +    public boolean getJsDefaultInitializers()
> > +    {
> > +        return jsDefaultInitializers;
> > +    }
> > +
> > +    @Config
> > +    @Mapping("js-default-initializers")
> > +    public void setJsDefaultInitializers(ConfigurationValue cv,
> boolean value)
> > +            throws ConfigurationException
> > +    {
> > +        jsDefaultInitializers = value;
> > +    }
> > +
> > +    //
> >     // 'compiler.js-external-library-path' option
> >     //
> >
> >
> > http://git-wip-us.apache.org/repos/asf/flex-falcon/blob/
> c500b3fe/compiler-jx/src/main/java/org/apache/flex/compiler/
> internal/codegen/js/jx/VarDeclarationEmitter.java
> > ----------------------------------------------------------------------
> > diff --git a/compiler-jx/src/main/java/org/apache/flex/compiler/
> internal/codegen/js/jx/VarDeclarationEmitter.java
> b/compiler-jx/src/main/java/org/apache/flex/compiler/
> internal/codegen/js/jx/VarDeclarationEmitter.java
> > index 4e35e39..e71c54e 100644
> > --- a/compiler-jx/src/main/java/org/apache/flex/compiler/
> internal/codegen/js/jx/VarDeclarationEmitter.java
> > +++ b/compiler-jx/src/main/java/org/apache/flex/compiler/
> internal/codegen/js/jx/VarDeclarationEmitter.java
> > @@ -21,6 +21,7 @@ package org.apache.flex.compiler.
> internal.codegen.js.jx;
> >
> > import org.apache.flex.compiler.codegen.ISubEmitter;
> > import org.apache.flex.compiler.codegen.js.IJSEmitter;
> > +import org.apache.flex.compiler.constants.IASKeywordConstants;
> > import org.apache.flex.compiler.constants.IASLanguageConstants;
> > import org.apache.flex.compiler.definitions.IDefinition;
> > import org.apache.flex.compiler.definitions.metadata.IMetaTag;
> > @@ -28,11 +29,13 @@ import org.apache.flex.compiler.
> definitions.metadata.IMetaTagAttribute;
> > import org.apache.flex.compiler.internal.codegen.as.ASEmitterTokens;
> > import org.apache.flex.compiler.internal.codegen.js.JSSubEmitter;
> > import org.apache.flex.compiler.internal.codegen.js.flexjs.
> JSFlexJSEmitter;
> > +import org.apache.flex.compiler.internal.projects.FlexJSProject;
> > import org.apache.flex.compiler.internal.tree.as.ChainedVariableNode;
> > import org.apache.flex.compiler.internal.tree.as.DynamicAccessNode;
> > import org.apache.flex.compiler.internal.tree.as.FunctionCallNode;
> > import org.apache.flex.compiler.internal.tree.as.IdentifierNode;
> > import org.apache.flex.compiler.internal.tree.as.
> MemberAccessExpressionNode;
> > +import org.apache.flex.compiler.projects.ICompilerProject;
> > import org.apache.flex.compiler.tree.ASTNodeID;
> > import org.apache.flex.compiler.tree.as.IASNode;
> > import org.apache.flex.compiler.tree.as.IEmbedNode;
> > @@ -182,18 +185,52 @@ public class VarDeclarationEmitter extends
> JSSubEmitter implements
> >                 typedef = enode.resolveType(getWalker().getProject());
> >             if (typedef != null)
> >             {
> > -                     String defName = typedef.getQualifiedName();
> > -                     if (defName.equals("int") ||
> defName.equals("uint"))
> > -                     {
> > -                             if (node.getParent() != null &&
> > -
>  node.getParent().getParent() != null &&
> > -
>  node.getParent().getParent().getNodeID() != ASTNodeID.Op_InID)
> > -                             {
> > -                                 write(ASEmitterTokens.SPACE);
> > -                                 writeToken(ASEmitterTokens.EQUAL);
> > -                                 write("0");
> > -                             }
> > -                     }
> > +                boolean defaultInitializers = false;
> > +                ICompilerProject project = getProject();
> > +                if(project instanceof FlexJSProject)
> > +                {
> > +                    FlexJSProject fjsProject = (FlexJSProject) project;
> > +                    if(fjsProject.config != null)
> > +                    {
> > +                        defaultInitializers = fjsProject.config.
> getJsDefaultInitializers();
> > +                    }
> > +                }
> > +                if (node.getParent() != null &&
> > +                        node.getParent().getParent() != null &&
> > +                        node.getParent().getParent().getNodeID() !=
> ASTNodeID.Op_InID)
> > +                {
> > +                    String defName = typedef.getQualifiedName();
> > +                    if (defName.equals("int") || defName.equals("uint"))
> > +                    {
> > +                        write(ASEmitterTokens.SPACE);
> > +                        writeToken(ASEmitterTokens.EQUAL);
> > +                        write("0");
> > +                    }
> > +                    if (defaultInitializers)
> > +                    {
> > +                        if (defName.equals("Number"))
> > +                        {
> > +                            write(ASEmitterTokens.SPACE);
> > +                            writeToken(ASEmitterTokens.EQUAL);
> > +                            write(IASKeywordConstants.NA_N);
> > +                        }
> > +                        else if (defName.equals("Boolean"))
> > +                        {
> > +                            write(ASEmitterTokens.SPACE);
> > +                            writeToken(ASEmitterTokens.EQUAL);
> > +                            write(IASKeywordConstants.FALSE);
> > +                        }
> > +                        else if (!defName.equals("*"))
> > +                        {
> > +                            //type * is meant to default to undefined,
> so it
> > +                            //doesn't need to be initialized, but
> everything
> > +                            //else should default to null
> > +                            write(ASEmitterTokens.SPACE);
> > +                            writeToken(ASEmitterTokens.EQUAL);
> > +                            write(IASKeywordConstants.NULL);
> > +                        }
> > +                    }
> > +                }
> >             }
> >         }
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Greg Dove
Maybe I'll convince others eventually.

fwiw Josh, I agree with you.

I agree undefined works the same as NaN for many things for example, but it
fails on very basic things like if (x is Number) .... that to me is quite
wrong and would be quite unexpected for anyone expecting flexjs
actionscript to behave like regular actionscript.
Perhaps there are ways to optimize it out in the compiler or GCL, but until
that happens I personally think the defaults should be actionscript
compatibility.




On Wed, Aug 2, 2017 at 9:54 AM, Josh Tynjala <[hidden email]> wrote:

> I think if booleans could fail even non-strict equality checks when they
> are not initialized, then we should always initialize booleans, like we
> currently do with int and uint. It doesn't even make sense to make it an
> option for booleans, if that's the case. It's just broken.
>
> I would still like the see the compiler initialize everything by default so
> that ActionScript behaves like ActionScript. I think we're making a mistake
> by making non-initialization the default. Maybe I'll convince others
> eventually.
>
> - Josh
>
> On Tue, Aug 1, 2017 at 11:09 AM, Harbs <[hidden email]> wrote:
>
> > One suggestion on this:
> >
> > Instead of making it a simple true/false, I’d suggest a tristate control
> > of true/false/booleans.
> >
> > The reason I’m making that suggestion is because even without strict
> > equality, setting booleans to false has the benefit that bool1 == bool2
> > will work as expected where undefined might not.
> >
> > FWIW, I have discovered that undefined for Numbers generally behaves the
> > same as NaN. I have also discovered that it’s very useful to NOT
> initialize
> > Numbers. Most NaN math errors I get are due to math with numbers which
> have
> > not been properly initialized. Anytime I get an unexpected NaN value,
> I’ve
> > found it’s very easy to walk up the stack trace to discover where math
> has
> > been done with an undefined value which basically without fail exposes
> the
> > bug. Initializing the values to NaN would mask the issues and make them
> > harder to find.
> >
> > My $0.02,
> > Harbs
> >
> > > On Aug 1, 2017, at 1:02 AM, [hidden email] wrote:
> > >
> > > Repository: flex-falcon
> > > Updated Branches:
> > >  refs/heads/develop b04074bf0 -> c500b3fe5
> > >
> > >
> > > compiler-jx: Added -js-default-initializers option to force
> > uninitialized variables to default to the same values in JS as they do in
> > SWF.
> > >
> > > -js-default-initializers defaults to false and is completely optional,
> > but may be useful for porting SWF projects to JS if an existing codebase
> > uses strict equality and relies on the SWF default initializers.
> > >
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/flex-falcon/repo
> > > Commit: http://git-wip-us.apache.org/repos/asf/flex-falcon/commit/
> > c500b3fe
> > > Tree: http://git-wip-us.apache.org/repos/asf/flex-falcon/tree/c500b3fe
> > > Diff: http://git-wip-us.apache.org/repos/asf/flex-falcon/diff/c500b3fe
> > >
> > > Branch: refs/heads/develop
> > > Commit: c500b3fe52299272dbf201033723296057c79413
> > > Parents: b04074b
> > > Author: Josh Tynjala <[hidden email]>
> > > Authored: Mon Jul 31 14:47:24 2017 -0700
> > > Committer: Josh Tynjala <[hidden email]>
> > > Committed: Mon Jul 31 14:54:24 2017 -0700
> > >
> > > ----------------------------------------------------------------------
> > > .../flex/compiler/clients/JSConfiguration.java  | 19 ++++++
> > > .../codegen/js/jx/VarDeclarationEmitter.java    | 61
> > ++++++++++++++++----
> > > 2 files changed, 68 insertions(+), 12 deletions(-)
> > > ----------------------------------------------------------------------
> > >
> > >
> > > http://git-wip-us.apache.org/repos/asf/flex-falcon/blob/
> > c500b3fe/compiler-jx/src/main/java/org/apache/flex/compiler/
> > clients/JSConfiguration.java
> > > ----------------------------------------------------------------------
> > > diff --git a/compiler-jx/src/main/java/org/apache/flex/compiler/
> clients/JSConfiguration.java
> > b/compiler-jx/src/main/java/org/apache/flex/compiler/
> > clients/JSConfiguration.java
> > > index ab1c73c..9f6bbe9 100644
> > > --- a/compiler-jx/src/main/java/org/apache/flex/compiler/
> > clients/JSConfiguration.java
> > > +++ b/compiler-jx/src/main/java/org/apache/flex/compiler/
> > clients/JSConfiguration.java
> > > @@ -118,6 +118,25 @@ public class JSConfiguration extends Configuration
> > >     }
> > >
> > >     //
> > > +    // 'js-default-initializers'
> > > +    //
> > > +
> > > +    private boolean jsDefaultInitializers = false;
> > > +
> > > +    public boolean getJsDefaultInitializers()
> > > +    {
> > > +        return jsDefaultInitializers;
> > > +    }
> > > +
> > > +    @Config
> > > +    @Mapping("js-default-initializers")
> > > +    public void setJsDefaultInitializers(ConfigurationValue cv,
> > boolean value)
> > > +            throws ConfigurationException
> > > +    {
> > > +        jsDefaultInitializers = value;
> > > +    }
> > > +
> > > +    //
> > >     // 'compiler.js-external-library-path' option
> > >     //
> > >
> > >
> > > http://git-wip-us.apache.org/repos/asf/flex-falcon/blob/
> > c500b3fe/compiler-jx/src/main/java/org/apache/flex/compiler/
> > internal/codegen/js/jx/VarDeclarationEmitter.java
> > > ----------------------------------------------------------------------
> > > diff --git a/compiler-jx/src/main/java/org/apache/flex/compiler/
> > internal/codegen/js/jx/VarDeclarationEmitter.java
> > b/compiler-jx/src/main/java/org/apache/flex/compiler/
> > internal/codegen/js/jx/VarDeclarationEmitter.java
> > > index 4e35e39..e71c54e 100644
> > > --- a/compiler-jx/src/main/java/org/apache/flex/compiler/
> > internal/codegen/js/jx/VarDeclarationEmitter.java
> > > +++ b/compiler-jx/src/main/java/org/apache/flex/compiler/
> > internal/codegen/js/jx/VarDeclarationEmitter.java
> > > @@ -21,6 +21,7 @@ package org.apache.flex.compiler.
> > internal.codegen.js.jx;
> > >
> > > import org.apache.flex.compiler.codegen.ISubEmitter;
> > > import org.apache.flex.compiler.codegen.js.IJSEmitter;
> > > +import org.apache.flex.compiler.constants.IASKeywordConstants;
> > > import org.apache.flex.compiler.constants.IASLanguageConstants;
> > > import org.apache.flex.compiler.definitions.IDefinition;
> > > import org.apache.flex.compiler.definitions.metadata.IMetaTag;
> > > @@ -28,11 +29,13 @@ import org.apache.flex.compiler.
> > definitions.metadata.IMetaTagAttribute;
> > > import org.apache.flex.compiler.internal.codegen.as.ASEmitterTokens;
> > > import org.apache.flex.compiler.internal.codegen.js.JSSubEmitter;
> > > import org.apache.flex.compiler.internal.codegen.js.flexjs.
> > JSFlexJSEmitter;
> > > +import org.apache.flex.compiler.internal.projects.FlexJSProject;
> > > import org.apache.flex.compiler.internal.tree.as.ChainedVariableNode;
> > > import org.apache.flex.compiler.internal.tree.as.DynamicAccessNode;
> > > import org.apache.flex.compiler.internal.tree.as.FunctionCallNode;
> > > import org.apache.flex.compiler.internal.tree.as.IdentifierNode;
> > > import org.apache.flex.compiler.internal.tree.as.
> > MemberAccessExpressionNode;
> > > +import org.apache.flex.compiler.projects.ICompilerProject;
> > > import org.apache.flex.compiler.tree.ASTNodeID;
> > > import org.apache.flex.compiler.tree.as.IASNode;
> > > import org.apache.flex.compiler.tree.as.IEmbedNode;
> > > @@ -182,18 +185,52 @@ public class VarDeclarationEmitter extends
> > JSSubEmitter implements
> > >                 typedef = enode.resolveType(getWalker().getProject());
> > >             if (typedef != null)
> > >             {
> > > -                     String defName = typedef.getQualifiedName();
> > > -                     if (defName.equals("int") ||
> > defName.equals("uint"))
> > > -                     {
> > > -                             if (node.getParent() != null &&
> > > -
> >  node.getParent().getParent() != null &&
> > > -
> >  node.getParent().getParent().getNodeID() != ASTNodeID.Op_InID)
> > > -                             {
> > > -                                 write(ASEmitterTokens.SPACE);
> > > -                                 writeToken(ASEmitterTokens.EQUAL);
> > > -                                 write("0");
> > > -                             }
> > > -                     }
> > > +                boolean defaultInitializers = false;
> > > +                ICompilerProject project = getProject();
> > > +                if(project instanceof FlexJSProject)
> > > +                {
> > > +                    FlexJSProject fjsProject = (FlexJSProject)
> project;
> > > +                    if(fjsProject.config != null)
> > > +                    {
> > > +                        defaultInitializers = fjsProject.config.
> > getJsDefaultInitializers();
> > > +                    }
> > > +                }
> > > +                if (node.getParent() != null &&
> > > +                        node.getParent().getParent() != null &&
> > > +                        node.getParent().getParent().getNodeID() !=
> > ASTNodeID.Op_InID)
> > > +                {
> > > +                    String defName = typedef.getQualifiedName();
> > > +                    if (defName.equals("int") ||
> defName.equals("uint"))
> > > +                    {
> > > +                        write(ASEmitterTokens.SPACE);
> > > +                        writeToken(ASEmitterTokens.EQUAL);
> > > +                        write("0");
> > > +                    }
> > > +                    if (defaultInitializers)
> > > +                    {
> > > +                        if (defName.equals("Number"))
> > > +                        {
> > > +                            write(ASEmitterTokens.SPACE);
> > > +                            writeToken(ASEmitterTokens.EQUAL);
> > > +                            write(IASKeywordConstants.NA_N);
> > > +                        }
> > > +                        else if (defName.equals("Boolean"))
> > > +                        {
> > > +                            write(ASEmitterTokens.SPACE);
> > > +                            writeToken(ASEmitterTokens.EQUAL);
> > > +                            write(IASKeywordConstants.FALSE);
> > > +                        }
> > > +                        else if (!defName.equals("*"))
> > > +                        {
> > > +                            //type * is meant to default to undefined,
> > so it
> > > +                            //doesn't need to be initialized, but
> > everything
> > > +                            //else should default to null
> > > +                            write(ASEmitterTokens.SPACE);
> > > +                            writeToken(ASEmitterTokens.EQUAL);
> > > +                            write(IASKeywordConstants.NULL);
> > > +                        }
> > > +                    }
> > > +                }
> > >             }
> > >         }
> > >
> > >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Harbs
In reply to this post by Josh Tynjala
Any maybe vice versa... ;-p

Alex was planning on looking into whether he can solve the boolean problem, so let’s hold off until he does that.

I think comparing two booleans is pretty rare although I have already run into if(myBool == false) not working. Changing it to if(!myBool) was simple enough, but I do agree with you that it’s currently broken.

For now, we’re going to have to agree to disagree on initializing values. I’ve seen a lot of value in leaving them undefined. It makes it really clear while debugging whether the value has been set or not.

Harbs

> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]> wrote:
>
> Maybe I'll convince others eventually.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Harbs
In reply to this post by Greg Dove
Interesting.

I’m not sure that I realized that NaN passes that test. Does it?

> On Aug 2, 2017, at 1:12 AM, Greg Dove <[hidden email]> wrote:
>
> I agree undefined works the same as NaN for many things for example, but it
> fails on very basic things like if (x is Number)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Greg Dove
Yes it does. NaN is an 'instance' of the Number type (even though it is
'Not a Number' ;)  )


On Wed, Aug 2, 2017 at 10:18 AM, Harbs <[hidden email]> wrote:

> Interesting.
>
> I’m not sure that I realized that NaN passes that test. Does it?
>
> > On Aug 2, 2017, at 1:12 AM, Greg Dove <[hidden email]> wrote:
> >
> > I agree undefined works the same as NaN for many things for example, but
> it
> > fails on very basic things like if (x is Number)
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Josh Tynjala
In reply to this post by Harbs
Don't get me wrong. If you see value in it, then we definitely shouldn't
remove it as an option. However, for compatibility with the existing
language, I'd prefer to see initialization be the default instead.

- Josh

On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:

> Any maybe vice versa... ;-p
>
> Alex was planning on looking into whether he can solve the boolean
> problem, so let’s hold off until he does that.
>
> I think comparing two booleans is pretty rare although I have already run
> into if(myBool == false) not working. Changing it to if(!myBool) was simple
> enough, but I do agree with you that it’s currently broken.
>
> For now, we’re going to have to agree to disagree on initializing values.
> I’ve seen a lot of value in leaving them undefined. It makes it really
> clear while debugging whether the value has been set or not.
>
> Harbs
>
> > On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]> wrote:
> >
> > Maybe I'll convince others eventually.
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Harbs
I’d prefer if we could somehow get the best of both worlds.

I don’t see a solution to that dilemma at the moment, but maybe we’ll come up with something...

Harbs

> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]> wrote:
>
> Don't get me wrong. If you see value in it, then we definitely shouldn't
> remove it as an option. However, for compatibility with the existing
> language, I'd prefer to see initialization be the default instead.
>
> - Josh
>
> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
>
>> Any maybe vice versa... ;-p
>>
>> Alex was planning on looking into whether he can solve the boolean
>> problem, so let’s hold off until he does that.
>>
>> I think comparing two booleans is pretty rare although I have already run
>> into if(myBool == false) not working. Changing it to if(!myBool) was simple
>> enough, but I do agree with you that it’s currently broken.
>>
>> For now, we’re going to have to agree to disagree on initializing values.
>> I’ve seen a lot of value in leaving them undefined. It makes it really
>> clear while debugging whether the value has been set or not.
>>
>> Harbs
>>
>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]> wrote:
>>>
>>> Maybe I'll convince others eventually.
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Justin Mclean
Administrator
In reply to this post by Josh Tynjala
Hi,

> I think if booleans could fail even non-strict equality checks when they
> are not initialized, then we should always initialize booleans, like we
> currently do with int and uint.

+1

> I would still like the see the compiler initialize everything by default so
> that ActionScript behaves like ActionScript. I think we're making a mistake
> by making non-initialization the default. Maybe I'll convince others
> eventually.

No need to convince me less bugs and no implicit casting is a better thing.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Greg Dove
In reply to this post by Harbs
I’d prefer if we could somehow get the best of both worlds.

Sorry Harbs, but I don't get it. I think the agreement is already to 'have
the best of both worlds'.
The issue is what the default should be. I know that you don't think you
could have both behaviours as the default :).

If we take away personal preferences, and think in terms of where
developers will be coming from for FlexJS, and if we assume that this
includes a large proportion of people who are already familiar with
actionscript and therefore have expectations based on that familiarity,
then I don't see how having default behaviour that is different to those
expectations will be helpful to the uptake in use of flexjs.

If it is not the case then we need to have documentation that supports the
divergence from official actionscript language documentation elsewhere, and
the hope that new users will read it as the authoritative source.


On Wed, Aug 2, 2017 at 10:31 AM, Harbs <[hidden email]> wrote:

> I’d prefer if we could somehow get the best of both worlds.
>
> I don’t see a solution to that dilemma at the moment, but maybe we’ll come
> up with something...
>
> Harbs
>
> > On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]> wrote:
> >
> > Don't get me wrong. If you see value in it, then we definitely shouldn't
> > remove it as an option. However, for compatibility with the existing
> > language, I'd prefer to see initialization be the default instead.
> >
> > - Josh
> >
> > On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
> >
> >> Any maybe vice versa... ;-p
> >>
> >> Alex was planning on looking into whether he can solve the boolean
> >> problem, so let’s hold off until he does that.
> >>
> >> I think comparing two booleans is pretty rare although I have already
> run
> >> into if(myBool == false) not working. Changing it to if(!myBool) was
> simple
> >> enough, but I do agree with you that it’s currently broken.
> >>
> >> For now, we’re going to have to agree to disagree on initializing
> values.
> >> I’ve seen a lot of value in leaving them undefined. It makes it really
> >> clear while debugging whether the value has been set or not.
> >>
> >> Harbs
> >>
> >>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
> wrote:
> >>>
> >>> Maybe I'll convince others eventually.
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Josh Tynjala
In reply to this post by Harbs
I'll bet that most of time that non-initialized values bite me is when I'm
checking if a member variable is null or not. I frequently rely on the fact
that Object, String, and most classes default to null, and then I do
something like this:

if(this._myVar === null)
{
}

I dread the day I need to go in and initialize a ton of variables that
didn't need to be initialized before (across hundreds of classes). Even
with this new option, if I port an open source library like Feathers, I'm
not going to force everyone who uses it to add
-js-default-initializers=true to their project's compiler options when they
want to add my library's source code to their project. That would be a bad
user experience. I've started trying to manually initialize to null when I
add new member variables to Feathers with the idea that this might be
required someday, but there's still a ton of existing code that will take a
very long time for me to update.

I wonder if there's some value in initializing only member variables, and
not locals (which I don't usually declare without initializing them). That
seems like it could be confusing, though. Or maybe null is worth
considering as a special case that's always initialized too. It seems
pretty very difficult to get the best of both worlds here.

- Josh

On Tue, Aug 1, 2017 at 3:31 PM, Harbs <[hidden email]> wrote:

> I’d prefer if we could somehow get the best of both worlds.
>
> I don’t see a solution to that dilemma at the moment, but maybe we’ll come
> up with something...
>
> Harbs
>
> > On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]> wrote:
> >
> > Don't get me wrong. If you see value in it, then we definitely shouldn't
> > remove it as an option. However, for compatibility with the existing
> > language, I'd prefer to see initialization be the default instead.
> >
> > - Josh
> >
> > On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
> >
> >> Any maybe vice versa... ;-p
> >>
> >> Alex was planning on looking into whether he can solve the boolean
> >> problem, so let’s hold off until he does that.
> >>
> >> I think comparing two booleans is pretty rare although I have already
> run
> >> into if(myBool == false) not working. Changing it to if(!myBool) was
> simple
> >> enough, but I do agree with you that it’s currently broken.
> >>
> >> For now, we’re going to have to agree to disagree on initializing
> values.
> >> I’ve seen a lot of value in leaving them undefined. It makes it really
> >> clear while debugging whether the value has been set or not.
> >>
> >> Harbs
> >>
> >>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
> wrote:
> >>>
> >>> Maybe I'll convince others eventually.
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Harbs
In reply to this post by Greg Dove
What I mean is that if we can somehow have the values uninitialized in JS, but in all cases where uninitialized values somehow diverge with ActionScript behavior be solved (so the use cases would behave correctly), then we’d have the advantages of undefined together with expected AS behavior.

I don’t know that this is possible, but that would be ideal in my book.

If that’s not possible, then yes, I agree that two compiler options is the best we can do.

Hope that’s clearer,
Harbs

> On Aug 2, 2017, at 1:49 AM, Greg Dove <[hidden email]> wrote:
>
> I’d prefer if we could somehow get the best of both worlds.
>
> Sorry Harbs, but I don't get it. I think the agreement is already to 'have
> the best of both worlds'.
> The issue is what the default should be. I know that you don't think you
> could have both behaviours as the default :).
>
> If we take away personal preferences, and think in terms of where
> developers will be coming from for FlexJS, and if we assume that this
> includes a large proportion of people who are already familiar with
> actionscript and therefore have expectations based on that familiarity,
> then I don't see how having default behaviour that is different to those
> expectations will be helpful to the uptake in use of flexjs.
>
> If it is not the case then we need to have documentation that supports the
> divergence from official actionscript language documentation elsewhere, and
> the hope that new users will read it as the authoritative source.
>
>
> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <[hidden email]> wrote:
>
>> I’d prefer if we could somehow get the best of both worlds.
>>
>> I don’t see a solution to that dilemma at the moment, but maybe we’ll come
>> up with something...
>>
>> Harbs
>>
>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]> wrote:
>>>
>>> Don't get me wrong. If you see value in it, then we definitely shouldn't
>>> remove it as an option. However, for compatibility with the existing
>>> language, I'd prefer to see initialization be the default instead.
>>>
>>> - Josh
>>>
>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
>>>
>>>> Any maybe vice versa... ;-p
>>>>
>>>> Alex was planning on looking into whether he can solve the boolean
>>>> problem, so let’s hold off until he does that.
>>>>
>>>> I think comparing two booleans is pretty rare although I have already
>> run
>>>> into if(myBool == false) not working. Changing it to if(!myBool) was
>> simple
>>>> enough, but I do agree with you that it’s currently broken.
>>>>
>>>> For now, we’re going to have to agree to disagree on initializing
>> values.
>>>> I’ve seen a lot of value in leaving them undefined. It makes it really
>>>> clear while debugging whether the value has been set or not.
>>>>
>>>> Harbs
>>>>
>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
>> wrote:
>>>>>
>>>>> Maybe I'll convince others eventually.
>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Alex Harui-2
To me, this is all related to PAYG.  And also, coding "style" matters.  If
we want to allow every possible existing AS statement work as-is, then we
must initialize every variable that has a different default in JS.

I thought the results of the set of tests I ran was that some of those
patterns that expose the differences between JS and AS default values are
less efficient and/or less common that other patterns.  IOW, as mentioned
up thread "if (someBoolean === false)" is less code and just as fast if
you rewrite it as "if (!someBoolean)".  And so, my recommendation for the
framework code is that we take the time to try to use these more common
patterns and thus not need to initialize every variable.

Another outcome of the tests was the question as to whether our compiler
ought to some day learn to rewrite these inefficient patterns to further
reduce cases where initialization is required.  And to also ponder whether
Google Closure Compiler may some day get around to rewriting these
patterns.

Either way, if we know the framework works just fine with uninitialized
variables and may even be smaller and faster than if we used other
patterns that care about initialization values, we can allow all kinds of
output options for user code.   I just looked at the commit a few minutes
ago.  It is ok for now, but I'd suggest making the option not tri-state,
but rather, list the Classes that should be initialized.  Maybe your code
doesn't care if Numbers are initialized but does care that Booleans are.
Then you can opt in on Boolean initialization and not pay the price for
Number initialization.  So the option might look like:

-initialize-types=Boolean,Number,*

Or something like that.  Essentially, let folks control how verbose the
output is so they can decide whether to change their code or change the
output as needed instead of just-in-case.  In this same area of code, we
should probably add a warning about variables being uninitialized and
having different default values.

BTW, IIRC, VarDeclarationEmitter only handles local variables and not
instance variables.

My 2 cents,
-Alex

On 8/1/17, 8:48 PM, "Harbs" <[hidden email]> wrote:

>What I mean is that if we can somehow have the values uninitialized in
>JS, but in all cases where uninitialized values somehow diverge with
>ActionScript behavior be solved (so the use cases would behave
>correctly), then we’d have the advantages of undefined together with
>expected AS behavior.
>
>I don’t know that this is possible, but that would be ideal in my book.
>
>If that’s not possible, then yes, I agree that two compiler options is
>the best we can do.
>
>Hope that’s clearer,
>Harbs
>
>> On Aug 2, 2017, at 1:49 AM, Greg Dove <[hidden email]> wrote:
>>
>> I’d prefer if we could somehow get the best of both worlds.
>>
>> Sorry Harbs, but I don't get it. I think the agreement is already to
>>'have
>> the best of both worlds'.
>> The issue is what the default should be. I know that you don't think you
>> could have both behaviours as the default :).
>>
>> If we take away personal preferences, and think in terms of where
>> developers will be coming from for FlexJS, and if we assume that this
>> includes a large proportion of people who are already familiar with
>> actionscript and therefore have expectations based on that familiarity,
>> then I don't see how having default behaviour that is different to those
>> expectations will be helpful to the uptake in use of flexjs.
>>
>> If it is not the case then we need to have documentation that supports
>>the
>> divergence from official actionscript language documentation elsewhere,
>>and
>> the hope that new users will read it as the authoritative source.
>>
>>
>> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <[hidden email]> wrote:
>>
>>> I’d prefer if we could somehow get the best of both worlds.
>>>
>>> I don’t see a solution to that dilemma at the moment, but maybe we’ll
>>>come
>>> up with something...
>>>
>>> Harbs
>>>
>>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]>
>>>>wrote:
>>>>
>>>> Don't get me wrong. If you see value in it, then we definitely
>>>>shouldn't
>>>> remove it as an option. However, for compatibility with the existing
>>>> language, I'd prefer to see initialization be the default instead.
>>>>
>>>> - Josh
>>>>
>>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
>>>>
>>>>> Any maybe vice versa... ;-p
>>>>>
>>>>> Alex was planning on looking into whether he can solve the boolean
>>>>> problem, so let’s hold off until he does that.
>>>>>
>>>>> I think comparing two booleans is pretty rare although I have already
>>> run
>>>>> into if(myBool == false) not working. Changing it to if(!myBool) was
>>> simple
>>>>> enough, but I do agree with you that it’s currently broken.
>>>>>
>>>>> For now, we’re going to have to agree to disagree on initializing
>>> values.
>>>>> I’ve seen a lot of value in leaving them undefined. It makes it
>>>>>really
>>>>> clear while debugging whether the value has been set or not.
>>>>>
>>>>> Harbs
>>>>>
>>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
>>> wrote:
>>>>>>
>>>>>> Maybe I'll convince others eventually.
>>>>>
>>>>>
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Harbs
I’m planning on using the new compiler options to compile my app with and without initialization. I want to compare the app size of those two options after gzipping to see if there’s an impact on code size.

I’d also like to write up a doc with the pros and cons of both approaches and see if I can come up with a list of use cases where initialized vs uninitialized values behave differently. It might be interesting to see how many can be resolved without initialization.

If nothing else, it can serve as a guide for developers deciding which compiler option to use.

Thanks,
Harbs

> On Aug 2, 2017, at 7:34 AM, Alex Harui <[hidden email]> wrote:
>
> To me, this is all related to PAYG.  And also, coding "style" matters.  If
> we want to allow every possible existing AS statement work as-is, then we
> must initialize every variable that has a different default in JS.
>
> I thought the results of the set of tests I ran was that some of those
> patterns that expose the differences between JS and AS default values are
> less efficient and/or less common that other patterns.  IOW, as mentioned
> up thread "if (someBoolean === false)" is less code and just as fast if
> you rewrite it as "if (!someBoolean)".  And so, my recommendation for the
> framework code is that we take the time to try to use these more common
> patterns and thus not need to initialize every variable.
>
> Another outcome of the tests was the question as to whether our compiler
> ought to some day learn to rewrite these inefficient patterns to further
> reduce cases where initialization is required.  And to also ponder whether
> Google Closure Compiler may some day get around to rewriting these
> patterns.
>
> Either way, if we know the framework works just fine with uninitialized
> variables and may even be smaller and faster than if we used other
> patterns that care about initialization values, we can allow all kinds of
> output options for user code.   I just looked at the commit a few minutes
> ago.  It is ok for now, but I'd suggest making the option not tri-state,
> but rather, list the Classes that should be initialized.  Maybe your code
> doesn't care if Numbers are initialized but does care that Booleans are.
> Then you can opt in on Boolean initialization and not pay the price for
> Number initialization.  So the option might look like:
>
> -initialize-types=Boolean,Number,*
>
> Or something like that.  Essentially, let folks control how verbose the
> output is so they can decide whether to change their code or change the
> output as needed instead of just-in-case.  In this same area of code, we
> should probably add a warning about variables being uninitialized and
> having different default values.
>
> BTW, IIRC, VarDeclarationEmitter only handles local variables and not
> instance variables.
>
> My 2 cents,
> -Alex
>
> On 8/1/17, 8:48 PM, "Harbs" <[hidden email]> wrote:
>
>> What I mean is that if we can somehow have the values uninitialized in
>> JS, but in all cases where uninitialized values somehow diverge with
>> ActionScript behavior be solved (so the use cases would behave
>> correctly), then we’d have the advantages of undefined together with
>> expected AS behavior.
>>
>> I don’t know that this is possible, but that would be ideal in my book.
>>
>> If that’s not possible, then yes, I agree that two compiler options is
>> the best we can do.
>>
>> Hope that’s clearer,
>> Harbs
>>
>>> On Aug 2, 2017, at 1:49 AM, Greg Dove <[hidden email]> wrote:
>>>
>>> I’d prefer if we could somehow get the best of both worlds.
>>>
>>> Sorry Harbs, but I don't get it. I think the agreement is already to
>>> 'have
>>> the best of both worlds'.
>>> The issue is what the default should be. I know that you don't think you
>>> could have both behaviours as the default :).
>>>
>>> If we take away personal preferences, and think in terms of where
>>> developers will be coming from for FlexJS, and if we assume that this
>>> includes a large proportion of people who are already familiar with
>>> actionscript and therefore have expectations based on that familiarity,
>>> then I don't see how having default behaviour that is different to those
>>> expectations will be helpful to the uptake in use of flexjs.
>>>
>>> If it is not the case then we need to have documentation that supports
>>> the
>>> divergence from official actionscript language documentation elsewhere,
>>> and
>>> the hope that new users will read it as the authoritative source.
>>>
>>>
>>> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <[hidden email]> wrote:
>>>
>>>> I’d prefer if we could somehow get the best of both worlds.
>>>>
>>>> I don’t see a solution to that dilemma at the moment, but maybe we’ll
>>>> come
>>>> up with something...
>>>>
>>>> Harbs
>>>>
>>>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> Don't get me wrong. If you see value in it, then we definitely
>>>>> shouldn't
>>>>> remove it as an option. However, for compatibility with the existing
>>>>> language, I'd prefer to see initialization be the default instead.
>>>>>
>>>>> - Josh
>>>>>
>>>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
>>>>>
>>>>>> Any maybe vice versa... ;-p
>>>>>>
>>>>>> Alex was planning on looking into whether he can solve the boolean
>>>>>> problem, so let’s hold off until he does that.
>>>>>>
>>>>>> I think comparing two booleans is pretty rare although I have already
>>>> run
>>>>>> into if(myBool == false) not working. Changing it to if(!myBool) was
>>>> simple
>>>>>> enough, but I do agree with you that it’s currently broken.
>>>>>>
>>>>>> For now, we’re going to have to agree to disagree on initializing
>>>> values.
>>>>>> I’ve seen a lot of value in leaving them undefined. It makes it
>>>>>> really
>>>>>> clear while debugging whether the value has been set or not.
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
>>>> wrote:
>>>>>>>
>>>>>>> Maybe I'll convince others eventually.
>>>>>>
>>>>>>
>>>>
>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Greg Dove
That sounds great Harbs. It will be interesting to see the gzip
comparisons.

I suspect that there would have to be massive quantities of redundant
initializations to cause a meaningful performance impact, but keen to see
the data.

From my perspective I think the baseline should be as3 compatibility, which
I believe is what any new user to FlexJS will be hoping for (expecting?).

In much the same way Josh described the feathers codebase, I can't imagine
an enterprise flex user aiming to port a large flex codebase not wanting
flexjs to be more reliable out-of-the-box, with the subsequent possibility
to tune things based on granular settings and a specific 'coding style'. My
guess is that they would prefer to avoid 'Pain as you go' from incompatible
as3 justified by pay as you go.
The challenge for us then is to come up with the optimizations that both
you and Alex have mentioned, so that wherever possible the unneccessary
initializations are not expressed in the js output while still maintaining
as3 compatibility. Meanwhile the (possibly granular) options to globally
omit initializations could be opt-in.

I'm calling tron on this. But it's just my opinion of what users want. We
should canvas the users group or run a survey to see what prospective
flexjs users prefer/expect. I don't really care about this for my own use
(so long as the option to switch initializations on is available). I care
about it in terms of what impact it could have on first experiences that
many users will have, and how much that will affect the popularity of
FlexJS.

I've said my piece. I will leave it at that.



On Wed, Aug 2, 2017 at 8:25 PM, Harbs <[hidden email]> wrote:

> I’m planning on using the new compiler options to compile my app with and
> without initialization. I want to compare the app size of those two options
> after gzipping to see if there’s an impact on code size.
>
> I’d also like to write up a doc with the pros and cons of both approaches
> and see if I can come up with a list of use cases where initialized vs
> uninitialized values behave differently. It might be interesting to see how
> many can be resolved without initialization.
>
> If nothing else, it can serve as a guide for developers deciding which
> compiler option to use.
>
> Thanks,
> Harbs
>
> > On Aug 2, 2017, at 7:34 AM, Alex Harui <[hidden email]> wrote:
> >
> > To me, this is all related to PAYG.  And also, coding "style" matters.
> If
> > we want to allow every possible existing AS statement work as-is, then we
> > must initialize every variable that has a different default in JS.
> >
> > I thought the results of the set of tests I ran was that some of those
> > patterns that expose the differences between JS and AS default values are
> > less efficient and/or less common that other patterns.  IOW, as mentioned
> > up thread "if (someBoolean === false)" is less code and just as fast if
> > you rewrite it as "if (!someBoolean)".  And so, my recommendation for the
> > framework code is that we take the time to try to use these more common
> > patterns and thus not need to initialize every variable.
> >
> > Another outcome of the tests was the question as to whether our compiler
> > ought to some day learn to rewrite these inefficient patterns to further
> > reduce cases where initialization is required.  And to also ponder
> whether
> > Google Closure Compiler may some day get around to rewriting these
> > patterns.
> >
> > Either way, if we know the framework works just fine with uninitialized
> > variables and may even be smaller and faster than if we used other
> > patterns that care about initialization values, we can allow all kinds of
> > output options for user code.   I just looked at the commit a few minutes
> > ago.  It is ok for now, but I'd suggest making the option not tri-state,
> > but rather, list the Classes that should be initialized.  Maybe your code
> > doesn't care if Numbers are initialized but does care that Booleans are.
> > Then you can opt in on Boolean initialization and not pay the price for
> > Number initialization.  So the option might look like:
> >
> > -initialize-types=Boolean,Number,*
> >
> > Or something like that.  Essentially, let folks control how verbose the
> > output is so they can decide whether to change their code or change the
> > output as needed instead of just-in-case.  In this same area of code, we
> > should probably add a warning about variables being uninitialized and
> > having different default values.
> >
> > BTW, IIRC, VarDeclarationEmitter only handles local variables and not
> > instance variables.
> >
> > My 2 cents,
> > -Alex
> >
> > On 8/1/17, 8:48 PM, "Harbs" <[hidden email]> wrote:
> >
> >> What I mean is that if we can somehow have the values uninitialized in
> >> JS, but in all cases where uninitialized values somehow diverge with
> >> ActionScript behavior be solved (so the use cases would behave
> >> correctly), then we’d have the advantages of undefined together with
> >> expected AS behavior.
> >>
> >> I don’t know that this is possible, but that would be ideal in my book.
> >>
> >> If that’s not possible, then yes, I agree that two compiler options is
> >> the best we can do.
> >>
> >> Hope that’s clearer,
> >> Harbs
> >>
> >>> On Aug 2, 2017, at 1:49 AM, Greg Dove <[hidden email]> wrote:
> >>>
> >>> I’d prefer if we could somehow get the best of both worlds.
> >>>
> >>> Sorry Harbs, but I don't get it. I think the agreement is already to
> >>> 'have
> >>> the best of both worlds'.
> >>> The issue is what the default should be. I know that you don't think
> you
> >>> could have both behaviours as the default :).
> >>>
> >>> If we take away personal preferences, and think in terms of where
> >>> developers will be coming from for FlexJS, and if we assume that this
> >>> includes a large proportion of people who are already familiar with
> >>> actionscript and therefore have expectations based on that familiarity,
> >>> then I don't see how having default behaviour that is different to
> those
> >>> expectations will be helpful to the uptake in use of flexjs.
> >>>
> >>> If it is not the case then we need to have documentation that supports
> >>> the
> >>> divergence from official actionscript language documentation elsewhere,
> >>> and
> >>> the hope that new users will read it as the authoritative source.
> >>>
> >>>
> >>> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <[hidden email]> wrote:
> >>>
> >>>> I’d prefer if we could somehow get the best of both worlds.
> >>>>
> >>>> I don’t see a solution to that dilemma at the moment, but maybe we’ll
> >>>> come
> >>>> up with something...
> >>>>
> >>>> Harbs
> >>>>
> >>>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>> Don't get me wrong. If you see value in it, then we definitely
> >>>>> shouldn't
> >>>>> remove it as an option. However, for compatibility with the existing
> >>>>> language, I'd prefer to see initialization be the default instead.
> >>>>>
> >>>>> - Josh
> >>>>>
> >>>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
> >>>>>
> >>>>>> Any maybe vice versa... ;-p
> >>>>>>
> >>>>>> Alex was planning on looking into whether he can solve the boolean
> >>>>>> problem, so let’s hold off until he does that.
> >>>>>>
> >>>>>> I think comparing two booleans is pretty rare although I have
> already
> >>>> run
> >>>>>> into if(myBool == false) not working. Changing it to if(!myBool) was
> >>>> simple
> >>>>>> enough, but I do agree with you that it’s currently broken.
> >>>>>>
> >>>>>> For now, we’re going to have to agree to disagree on initializing
> >>>> values.
> >>>>>> I’ve seen a lot of value in leaving them undefined. It makes it
> >>>>>> really
> >>>>>> clear while debugging whether the value has been set or not.
> >>>>>>
> >>>>>> Harbs
> >>>>>>
> >>>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
> >>>> wrote:
> >>>>>>>
> >>>>>>> Maybe I'll convince others eventually.
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Harbs
In reply to this post by Alex Harui-2
Yes. I just tried the new compiler option and I can confirm that this is the case. Only local variables are initialized.

Additionally:

This:
var len:int;
Compiles to:
var /** @type {number} */ len = 0 = null;

> On Aug 2, 2017, at 7:34 AM, Alex Harui <[hidden email]> wrote:
>
> BTW, IIRC, VarDeclarationEmitter only handles local variables and not
> instance variables.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Harbs
In reply to this post by Greg Dove
> My guess is that they would prefer to avoid 'Pain as you go' from incompatible
> as3 justified by pay as you go.
> The challenge for us then is to come up with the optimizations that both
> you and Alex have mentioned, so that wherever possible the unneccessary
> initializations are not expressed in the js output while still maintaining
> as3 compatibility.

I completely agree with these statements. Challenges are fun. ;-) Give me some time to put together my doc and let’s see where that goes. I think having a clear list of the issues should be helpful.

Harbs

> On Aug 2, 2017, at 11:52 AM, Greg Dove <[hidden email]> wrote:
>
> That sounds great Harbs. It will be interesting to see the gzip
> comparisons.
>
> I suspect that there would have to be massive quantities of redundant
> initializations to cause a meaningful performance impact, but keen to see
> the data.
>
> From my perspective I think the baseline should be as3 compatibility, which
> I believe is what any new user to FlexJS will be hoping for (expecting?).
>
> In much the same way Josh described the feathers codebase, I can't imagine
> an enterprise flex user aiming to port a large flex codebase not wanting
> flexjs to be more reliable out-of-the-box, with the subsequent possibility
> to tune things based on granular settings and a specific 'coding style'. My
> guess is that they would prefer to avoid 'Pain as you go' from incompatible
> as3 justified by pay as you go.
> The challenge for us then is to come up with the optimizations that both
> you and Alex have mentioned, so that wherever possible the unneccessary
> initializations are not expressed in the js output while still maintaining
> as3 compatibility. Meanwhile the (possibly granular) options to globally
> omit initializations could be opt-in.
>
> I'm calling tron on this. But it's just my opinion of what users want. We
> should canvas the users group or run a survey to see what prospective
> flexjs users prefer/expect. I don't really care about this for my own use
> (so long as the option to switch initializations on is available). I care
> about it in terms of what impact it could have on first experiences that
> many users will have, and how much that will affect the popularity of
> FlexJS.
>
> I've said my piece. I will leave it at that.
>
>
>
> On Wed, Aug 2, 2017 at 8:25 PM, Harbs <[hidden email]> wrote:
>
>> I’m planning on using the new compiler options to compile my app with and
>> without initialization. I want to compare the app size of those two options
>> after gzipping to see if there’s an impact on code size.
>>
>> I’d also like to write up a doc with the pros and cons of both approaches
>> and see if I can come up with a list of use cases where initialized vs
>> uninitialized values behave differently. It might be interesting to see how
>> many can be resolved without initialization.
>>
>> If nothing else, it can serve as a guide for developers deciding which
>> compiler option to use.
>>
>> Thanks,
>> Harbs
>>
>>> On Aug 2, 2017, at 7:34 AM, Alex Harui <[hidden email]> wrote:
>>>
>>> To me, this is all related to PAYG.  And also, coding "style" matters.
>> If
>>> we want to allow every possible existing AS statement work as-is, then we
>>> must initialize every variable that has a different default in JS.
>>>
>>> I thought the results of the set of tests I ran was that some of those
>>> patterns that expose the differences between JS and AS default values are
>>> less efficient and/or less common that other patterns.  IOW, as mentioned
>>> up thread "if (someBoolean === false)" is less code and just as fast if
>>> you rewrite it as "if (!someBoolean)".  And so, my recommendation for the
>>> framework code is that we take the time to try to use these more common
>>> patterns and thus not need to initialize every variable.
>>>
>>> Another outcome of the tests was the question as to whether our compiler
>>> ought to some day learn to rewrite these inefficient patterns to further
>>> reduce cases where initialization is required.  And to also ponder
>> whether
>>> Google Closure Compiler may some day get around to rewriting these
>>> patterns.
>>>
>>> Either way, if we know the framework works just fine with uninitialized
>>> variables and may even be smaller and faster than if we used other
>>> patterns that care about initialization values, we can allow all kinds of
>>> output options for user code.   I just looked at the commit a few minutes
>>> ago.  It is ok for now, but I'd suggest making the option not tri-state,
>>> but rather, list the Classes that should be initialized.  Maybe your code
>>> doesn't care if Numbers are initialized but does care that Booleans are.
>>> Then you can opt in on Boolean initialization and not pay the price for
>>> Number initialization.  So the option might look like:
>>>
>>> -initialize-types=Boolean,Number,*
>>>
>>> Or something like that.  Essentially, let folks control how verbose the
>>> output is so they can decide whether to change their code or change the
>>> output as needed instead of just-in-case.  In this same area of code, we
>>> should probably add a warning about variables being uninitialized and
>>> having different default values.
>>>
>>> BTW, IIRC, VarDeclarationEmitter only handles local variables and not
>>> instance variables.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 8/1/17, 8:48 PM, "Harbs" <[hidden email]> wrote:
>>>
>>>> What I mean is that if we can somehow have the values uninitialized in
>>>> JS, but in all cases where uninitialized values somehow diverge with
>>>> ActionScript behavior be solved (so the use cases would behave
>>>> correctly), then we’d have the advantages of undefined together with
>>>> expected AS behavior.
>>>>
>>>> I don’t know that this is possible, but that would be ideal in my book.
>>>>
>>>> If that’s not possible, then yes, I agree that two compiler options is
>>>> the best we can do.
>>>>
>>>> Hope that’s clearer,
>>>> Harbs
>>>>
>>>>> On Aug 2, 2017, at 1:49 AM, Greg Dove <[hidden email]> wrote:
>>>>>
>>>>> I’d prefer if we could somehow get the best of both worlds.
>>>>>
>>>>> Sorry Harbs, but I don't get it. I think the agreement is already to
>>>>> 'have
>>>>> the best of both worlds'.
>>>>> The issue is what the default should be. I know that you don't think
>> you
>>>>> could have both behaviours as the default :).
>>>>>
>>>>> If we take away personal preferences, and think in terms of where
>>>>> developers will be coming from for FlexJS, and if we assume that this
>>>>> includes a large proportion of people who are already familiar with
>>>>> actionscript and therefore have expectations based on that familiarity,
>>>>> then I don't see how having default behaviour that is different to
>> those
>>>>> expectations will be helpful to the uptake in use of flexjs.
>>>>>
>>>>> If it is not the case then we need to have documentation that supports
>>>>> the
>>>>> divergence from official actionscript language documentation elsewhere,
>>>>> and
>>>>> the hope that new users will read it as the authoritative source.
>>>>>
>>>>>
>>>>> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <[hidden email]> wrote:
>>>>>
>>>>>> I’d prefer if we could somehow get the best of both worlds.
>>>>>>
>>>>>> I don’t see a solution to that dilemma at the moment, but maybe we’ll
>>>>>> come
>>>>>> up with something...
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Don't get me wrong. If you see value in it, then we definitely
>>>>>>> shouldn't
>>>>>>> remove it as an option. However, for compatibility with the existing
>>>>>>> language, I'd prefer to see initialization be the default instead.
>>>>>>>
>>>>>>> - Josh
>>>>>>>
>>>>>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
>>>>>>>
>>>>>>>> Any maybe vice versa... ;-p
>>>>>>>>
>>>>>>>> Alex was planning on looking into whether he can solve the boolean
>>>>>>>> problem, so let’s hold off until he does that.
>>>>>>>>
>>>>>>>> I think comparing two booleans is pretty rare although I have
>> already
>>>>>> run
>>>>>>>> into if(myBool == false) not working. Changing it to if(!myBool) was
>>>>>> simple
>>>>>>>> enough, but I do agree with you that it’s currently broken.
>>>>>>>>
>>>>>>>> For now, we’re going to have to agree to disagree on initializing
>>>>>> values.
>>>>>>>> I’ve seen a lot of value in leaving them undefined. It makes it
>>>>>>>> really
>>>>>>>> clear while debugging whether the value has been set or not.
>>>>>>>>
>>>>>>>> Harbs
>>>>>>>>
>>>>>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Maybe I'll convince others eventually.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

piotrz
In reply to this post by Alex Harui-2
I really like Alex's proposition where we could have list of classes which should be initialized. Actually why do not have both? One global variable which makes all initialized or list of initialized.

Piotr

Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Josh Tynjala
In reply to this post by Alex Harui-2
> To me, this is all related to PAYG.

To me, making the compiler generate PAYG code by default sounds like the
FlexJS framework leaking into the rest of the ecosystem. Maybe this is a
place where mxmlc and asjsc should go in different directions. It makes
perfect sense to me for the compiler to do PAYG by default for the FlexJS
framework, but the rest of the world should get the a better user
experience with more compatibility by default (with the option to opt into
non-initialized PAYG mode). Thoughts?

> list the Classes that should be initialized.  Maybe your code
doesn't care if Numbers are initialized but does care that Booleans are.
Then you can opt in on Boolean initialization and not pay the price for
Number initialization.

It's an interesting idea. For nullable types, that list could get huge,
though. Boolean, int, uint, and Number are all special, but basically
everything else is nullable. I think there should still be a way to say "I
want everything initialized".

> BTW, IIRC, VarDeclarationEmitter only handles local variables and not
instance variables.

For some reason, I thought I remembered locals and members using the same
emitter. I'll update it elsewhere for members too.

- Josh

On Tue, Aug 1, 2017 at 9:34 PM, Alex Harui <[hidden email]> wrote:

> To me, this is all related to PAYG.  And also, coding "style" matters.  If
> we want to allow every possible existing AS statement work as-is, then we
> must initialize every variable that has a different default in JS.
>
> I thought the results of the set of tests I ran was that some of those
> patterns that expose the differences between JS and AS default values are
> less efficient and/or less common that other patterns.  IOW, as mentioned
> up thread "if (someBoolean === false)" is less code and just as fast if
> you rewrite it as "if (!someBoolean)".  And so, my recommendation for the
> framework code is that we take the time to try to use these more common
> patterns and thus not need to initialize every variable.
>
> Another outcome of the tests was the question as to whether our compiler
> ought to some day learn to rewrite these inefficient patterns to further
> reduce cases where initialization is required.  And to also ponder whether
> Google Closure Compiler may some day get around to rewriting these
> patterns.
>
> Either way, if we know the framework works just fine with uninitialized
> variables and may even be smaller and faster than if we used other
> patterns that care about initialization values, we can allow all kinds of
> output options for user code.   I just looked at the commit a few minutes
> ago.  It is ok for now, but I'd suggest making the option not tri-state,
> but rather, list the Classes that should be initialized.  Maybe your code
> doesn't care if Numbers are initialized but does care that Booleans are.
> Then you can opt in on Boolean initialization and not pay the price for
> Number initialization.  So the option might look like:
>
> -initialize-types=Boolean,Number,*
>
> Or something like that.  Essentially, let folks control how verbose the
> output is so they can decide whether to change their code or change the
> output as needed instead of just-in-case.  In this same area of code, we
> should probably add a warning about variables being uninitialized and
> having different default values.
>
> BTW, IIRC, VarDeclarationEmitter only handles local variables and not
> instance variables.
>
> My 2 cents,
> -Alex
>
> On 8/1/17, 8:48 PM, "Harbs" <[hidden email]> wrote:
>
> >What I mean is that if we can somehow have the values uninitialized in
> >JS, but in all cases where uninitialized values somehow diverge with
> >ActionScript behavior be solved (so the use cases would behave
> >correctly), then we’d have the advantages of undefined together with
> >expected AS behavior.
> >
> >I don’t know that this is possible, but that would be ideal in my book.
> >
> >If that’s not possible, then yes, I agree that two compiler options is
> >the best we can do.
> >
> >Hope that’s clearer,
> >Harbs
> >
> >> On Aug 2, 2017, at 1:49 AM, Greg Dove <[hidden email]> wrote:
> >>
> >> I’d prefer if we could somehow get the best of both worlds.
> >>
> >> Sorry Harbs, but I don't get it. I think the agreement is already to
> >>'have
> >> the best of both worlds'.
> >> The issue is what the default should be. I know that you don't think you
> >> could have both behaviours as the default :).
> >>
> >> If we take away personal preferences, and think in terms of where
> >> developers will be coming from for FlexJS, and if we assume that this
> >> includes a large proportion of people who are already familiar with
> >> actionscript and therefore have expectations based on that familiarity,
> >> then I don't see how having default behaviour that is different to those
> >> expectations will be helpful to the uptake in use of flexjs.
> >>
> >> If it is not the case then we need to have documentation that supports
> >>the
> >> divergence from official actionscript language documentation elsewhere,
> >>and
> >> the hope that new users will read it as the authoritative source.
> >>
> >>
> >> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <[hidden email]> wrote:
> >>
> >>> I’d prefer if we could somehow get the best of both worlds.
> >>>
> >>> I don’t see a solution to that dilemma at the moment, but maybe we’ll
> >>>come
> >>> up with something...
> >>>
> >>> Harbs
> >>>
> >>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]>
> >>>>wrote:
> >>>>
> >>>> Don't get me wrong. If you see value in it, then we definitely
> >>>>shouldn't
> >>>> remove it as an option. However, for compatibility with the existing
> >>>> language, I'd prefer to see initialization be the default instead.
> >>>>
> >>>> - Josh
> >>>>
> >>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]> wrote:
> >>>>
> >>>>> Any maybe vice versa... ;-p
> >>>>>
> >>>>> Alex was planning on looking into whether he can solve the boolean
> >>>>> problem, so let’s hold off until he does that.
> >>>>>
> >>>>> I think comparing two booleans is pretty rare although I have already
> >>> run
> >>>>> into if(myBool == false) not working. Changing it to if(!myBool) was
> >>> simple
> >>>>> enough, but I do agree with you that it’s currently broken.
> >>>>>
> >>>>> For now, we’re going to have to agree to disagree on initializing
> >>> values.
> >>>>> I’ve seen a lot of value in leaving them undefined. It makes it
> >>>>>really
> >>>>> clear while debugging whether the value has been set or not.
> >>>>>
> >>>>> Harbs
> >>>>>
> >>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
> >>> wrote:
> >>>>>>
> >>>>>> Maybe I'll convince others eventually.
> >>>>>
> >>>>>
> >>>
> >>>
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git commit: [flex-falcon] [refs/heads/develop] - compiler-jx: Added -js-default-initializers option to force uninitialized variables to default to the same values in JS as they do in SWF.

Alex Harui-2
We have flex-config.xml, air-config.xml, js-config.xml, etc.  These config
files are (or can be) different sets of defaults.

Meanwhile, we currently build the FlexJS framework via
compile-swf-config.xml and compile-js-config.xml and its equivalent in
pom.xml.  I have no problem using different defaults for the FlexJS
framework and different defaults for compiling apps.  We already supply
certain kinds of optimizations via @flexjsignorcoercion.  IOW, there is
precedence for controlling the kinds of JS output we generate.

We provide an Express component set with different defaults than Basic and
produces fatter slower apps but should make it easier to get your app up
and running.  We can certainly have the compiler start out by producing
fatter slower code as well as long as it doesn't give a negative first
impression of app size.  We just have to make it possible to shave off
code to improve download size and performance if/when someone needs it.

Regarding the list of nullable types, I agree there should be some
wildcard for all instances.

My 2 cents,
-Alex

On 8/2/17, 7:06 AM, "Josh Tynjala" <[hidden email]> wrote:

>> To me, this is all related to PAYG.
>
>To me, making the compiler generate PAYG code by default sounds like the
>FlexJS framework leaking into the rest of the ecosystem. Maybe this is a
>place where mxmlc and asjsc should go in different directions. It makes
>perfect sense to me for the compiler to do PAYG by default for the FlexJS
>framework, but the rest of the world should get the a better user
>experience with more compatibility by default (with the option to opt into
>non-initialized PAYG mode). Thoughts?
>
>> list the Classes that should be initialized.  Maybe your code
>doesn't care if Numbers are initialized but does care that Booleans are.
>Then you can opt in on Boolean initialization and not pay the price for
>Number initialization.
>
>It's an interesting idea. For nullable types, that list could get huge,
>though. Boolean, int, uint, and Number are all special, but basically
>everything else is nullable. I think there should still be a way to say "I
>want everything initialized".
>
>> BTW, IIRC, VarDeclarationEmitter only handles local variables and not
>instance variables.
>
>For some reason, I thought I remembered locals and members using the same
>emitter. I'll update it elsewhere for members too.
>
>- Josh
>
>On Tue, Aug 1, 2017 at 9:34 PM, Alex Harui <[hidden email]>
>wrote:
>
>> To me, this is all related to PAYG.  And also, coding "style" matters.
>>If
>> we want to allow every possible existing AS statement work as-is, then
>>we
>> must initialize every variable that has a different default in JS.
>>
>> I thought the results of the set of tests I ran was that some of those
>> patterns that expose the differences between JS and AS default values
>>are
>> less efficient and/or less common that other patterns.  IOW, as
>>mentioned
>> up thread "if (someBoolean === false)" is less code and just as fast if
>> you rewrite it as "if (!someBoolean)".  And so, my recommendation for
>>the
>> framework code is that we take the time to try to use these more common
>> patterns and thus not need to initialize every variable.
>>
>> Another outcome of the tests was the question as to whether our compiler
>> ought to some day learn to rewrite these inefficient patterns to further
>> reduce cases where initialization is required.  And to also ponder
>>whether
>> Google Closure Compiler may some day get around to rewriting these
>> patterns.
>>
>> Either way, if we know the framework works just fine with uninitialized
>> variables and may even be smaller and faster than if we used other
>> patterns that care about initialization values, we can allow all kinds
>>of
>> output options for user code.   I just looked at the commit a few
>>minutes
>> ago.  It is ok for now, but I'd suggest making the option not tri-state,
>> but rather, list the Classes that should be initialized.  Maybe your
>>code
>> doesn't care if Numbers are initialized but does care that Booleans are.
>> Then you can opt in on Boolean initialization and not pay the price for
>> Number initialization.  So the option might look like:
>>
>> -initialize-types=Boolean,Number,*
>>
>> Or something like that.  Essentially, let folks control how verbose the
>> output is so they can decide whether to change their code or change the
>> output as needed instead of just-in-case.  In this same area of code, we
>> should probably add a warning about variables being uninitialized and
>> having different default values.
>>
>> BTW, IIRC, VarDeclarationEmitter only handles local variables and not
>> instance variables.
>>
>> My 2 cents,
>> -Alex
>>
>> On 8/1/17, 8:48 PM, "Harbs" <[hidden email]> wrote:
>>
>> >What I mean is that if we can somehow have the values uninitialized in
>> >JS, but in all cases where uninitialized values somehow diverge with
>> >ActionScript behavior be solved (so the use cases would behave
>> >correctly), then we’d have the advantages of undefined together with
>> >expected AS behavior.
>> >
>> >I don’t know that this is possible, but that would be ideal in my book.
>> >
>> >If that’s not possible, then yes, I agree that two compiler options is
>> >the best we can do.
>> >
>> >Hope that’s clearer,
>> >Harbs
>> >
>> >> On Aug 2, 2017, at 1:49 AM, Greg Dove <[hidden email]> wrote:
>> >>
>> >> I’d prefer if we could somehow get the best of both worlds.
>> >>
>> >> Sorry Harbs, but I don't get it. I think the agreement is already to
>> >>'have
>> >> the best of both worlds'.
>> >> The issue is what the default should be. I know that you don't think
>>you
>> >> could have both behaviours as the default :).
>> >>
>> >> If we take away personal preferences, and think in terms of where
>> >> developers will be coming from for FlexJS, and if we assume that this
>> >> includes a large proportion of people who are already familiar with
>> >> actionscript and therefore have expectations based on that
>>familiarity,
>> >> then I don't see how having default behaviour that is different to
>>those
>> >> expectations will be helpful to the uptake in use of flexjs.
>> >>
>> >> If it is not the case then we need to have documentation that
>>supports
>> >>the
>> >> divergence from official actionscript language documentation
>>elsewhere,
>> >>and
>> >> the hope that new users will read it as the authoritative source.
>> >>
>> >>
>> >> On Wed, Aug 2, 2017 at 10:31 AM, Harbs <[hidden email]> wrote:
>> >>
>> >>> I’d prefer if we could somehow get the best of both worlds.
>> >>>
>> >>> I don’t see a solution to that dilemma at the moment, but maybe
>>we’ll
>> >>>come
>> >>> up with something...
>> >>>
>> >>> Harbs
>> >>>
>> >>>> On Aug 2, 2017, at 1:24 AM, Josh Tynjala <[hidden email]>
>> >>>>wrote:
>> >>>>
>> >>>> Don't get me wrong. If you see value in it, then we definitely
>> >>>>shouldn't
>> >>>> remove it as an option. However, for compatibility with the
>>existing
>> >>>> language, I'd prefer to see initialization be the default instead.
>> >>>>
>> >>>> - Josh
>> >>>>
>> >>>> On Tue, Aug 1, 2017 at 3:14 PM, Harbs <[hidden email]>
>>wrote:
>> >>>>
>> >>>>> Any maybe vice versa... ;-p
>> >>>>>
>> >>>>> Alex was planning on looking into whether he can solve the boolean
>> >>>>> problem, so let’s hold off until he does that.
>> >>>>>
>> >>>>> I think comparing two booleans is pretty rare although I have
>>already
>> >>> run
>> >>>>> into if(myBool == false) not working. Changing it to if(!myBool)
>>was
>> >>> simple
>> >>>>> enough, but I do agree with you that it’s currently broken.
>> >>>>>
>> >>>>> For now, we’re going to have to agree to disagree on initializing
>> >>> values.
>> >>>>> I’ve seen a lot of value in leaving them undefined. It makes it
>> >>>>>really
>> >>>>> clear while debugging whether the value has been set or not.
>> >>>>>
>> >>>>> Harbs
>> >>>>>
>> >>>>>> On Aug 2, 2017, at 12:54 AM, Josh Tynjala <[hidden email]>
>> >>> wrote:
>> >>>>>>
>> >>>>>> Maybe I'll convince others eventually.
>> >>>>>
>> >>>>>
>> >>>
>> >>>
>> >
>>
>>

12
Loading...