You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/08/01 18:09:39 UTC
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.
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, joshtynjala@apache.org 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 <jo...@apache.org>
> Authored: Mon Jul 31 14:47:24 2017 -0700
> Committer: Josh Tynjala <jo...@apache.org>
> 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);
> + }
> + }
> + }
> }
> }
>
>
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.
Posted by Justin Mclean <ju...@classsoftware.com>.
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
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.
Posted by Josh Tynjala <jo...@gmail.com>.
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 <ha...@gmail.com> 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 <jo...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
> wrote:
> >>>
> >>> Maybe I'll convince others eventually.
> >>
> >>
>
>
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.
Posted by Josh Tynjala <jo...@gmail.com>.
I like the idea of having the FlexJS framework specify non-initialization
with its config files, and then most users will get initialization by
default (obviously, with the option to have non-initialization too, if
desired).
- Josh
On Wed, Aug 2, 2017 at 2:16 PM, Alex Harui <ah...@adobe.com.invalid> wrote:
> 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" <jo...@gmail.com> 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 <ah...@adobe.com.invalid>
> >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" <ha...@gmail.com> 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 <gr...@gmail.com> 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 <ha...@gmail.com>
> 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 <jo...@gmail.com>
> >> >>>>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 <ha...@gmail.com>
> >>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 <joshtynjala@gmail.com
> >
> >> >>> wrote:
> >> >>>>>>
> >> >>>>>> Maybe I'll convince others eventually.
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>>
> >> >
> >>
> >>
>
>
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.
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <jo...@gmail.com> 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 <ah...@adobe.com.invalid>
>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" <ha...@gmail.com> 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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
>> >>>>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 <ha...@gmail.com>
>>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 <jo...@gmail.com>
>> >>> wrote:
>> >>>>>>
>> >>>>>> Maybe I'll convince others eventually.
>> >>>>>
>> >>>>>
>> >>>
>> >>>
>> >
>>
>>
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.
Posted by Josh Tynjala <jo...@gmail.com>.
> 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 <ah...@adobe.com.invalid> 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" <ha...@gmail.com> 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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
> >>>>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 <ha...@gmail.com> 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 <jo...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>> Maybe I'll convince others eventually.
> >>>>>
> >>>>>
> >>>
> >>>
> >
>
>
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.
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> wrote:
>
> BTW, IIRC, VarDeclarationEmitter only handles local variables and not
> instance variables.
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.
Posted by piotrz <pi...@gmail.com>.
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
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Re-git-commit-flex-falcon-refs-heads-develop-compiler-jx-Added-js-default-initializers-option-to-for-tp63636p63658.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
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.
Posted by Harbs <ha...@gmail.com>.
> 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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
>>>>>>> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Maybe I'll convince others eventually.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
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.
Posted by Greg Dove <gr...@gmail.com>.
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 <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
> >>>>> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>> Maybe I'll convince others eventually.
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >
>
>
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.
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
>>>>> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> Maybe I'll convince others eventually.
>>>>>>
>>>>>>
>>>>
>>>>
>>
>
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.
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> 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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
>>>>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 <ha...@gmail.com> 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 <jo...@gmail.com>
>>> wrote:
>>>>>>
>>>>>> Maybe I'll convince others eventually.
>>>>>
>>>>>
>>>
>>>
>
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.
Posted by Harbs <ha...@gmail.com>.
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 <gr...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
>> wrote:
>>>>>
>>>>> Maybe I'll convince others eventually.
>>>>
>>>>
>>
>>
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.
Posted by Greg Dove <gr...@gmail.com>.
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 <ha...@gmail.com> 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 <jo...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com>
> wrote:
> >>>
> >>> Maybe I'll convince others eventually.
> >>
> >>
>
>
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.
Posted by Harbs <ha...@gmail.com>.
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 <jo...@gmail.com> 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 <ha...@gmail.com> 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 <jo...@gmail.com> wrote:
>>>
>>> Maybe I'll convince others eventually.
>>
>>
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.
Posted by Josh Tynjala <jo...@gmail.com>.
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 <ha...@gmail.com> 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 <jo...@gmail.com> wrote:
> >
> > Maybe I'll convince others eventually.
>
>
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.
Posted by Harbs <ha...@gmail.com>.
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 <jo...@gmail.com> wrote:
>
> Maybe I'll convince others eventually.
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.
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, it matters whether you are strictly/strongly typing or not.
I have not spent the time to see what the compiler does for:
var foo:String;
if (isNaN(foo))
Do you get a compiler error? Or is it allowed and auto-coercion in the
Flash runtime will do what JS does?
You are correct that if you never compile against the SWF target you will
be allowed to pass things other than Number into isNaN. I wonder if we
should change that?
I agree that we probably can't change all isNaN calls to "someNumber !==
someNumber" and only those where we know the thing passed in is a Number,
but on the other hand, I think if you have compiled against the Flash
isNaN, the thing passed in must always be a Number.
-Alex
On 8/3/17, 7:42 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
>It seems dangerous to replace isNaN with someNumber !== someNumber. In
>that
>article, they said that isNaN() could return false positives, but I don't
>actually consider their example to be a false positive at all. I would
>fully expect isNaN() to return true for a string value. If we replaced
>that
>example call to isNaN() with !==, and the result became false instead of
>true, I would consider it a bug.
>
>In Flash/AIR, isNaN() accepts only type Number. In the JS typedefs,
>isNaN()
>accepts anything. I guess if the type of the variable is known to be
>Number, the compiler could switch to !==. If it's a different type, we
>should probably keep using isNaN(). For some types, we may even be able to
>assume that isNaN() will always return true. However, we need to be
>careful
>about edge cases. A Number could be stored in type Object, for instance.
>
>- Josh
>
>On Thu, Aug 3, 2017 at 7:22 AM, Alex Harui <ah...@adobe.com.invalid>
>wrote:
>
>> Here's an article about isNaN is JS.
>>
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fadripofja
>>vascript.com%2Fblog%2Fdrips%2Fthe-problem-with-&data=02%7C01%7C%7C918c1ea
>>c90934780354c08d4da7dfef4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63
>>6373682092107341&sdata=Lro5rBYWF4lnJEAmcHTzMT0GIhCnI8Zgp7E8af9DLlw%3D&res
>>erved=0
>> testing-for-nan-in
>> -javascript.html
>>
>> Maybe the transpiler should not output isNaN and instead "someNumber !==
>> someNumber"
>>
>> -Alex
>>
>> On 8/3/17, 6:30 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> >Cool.
>> >
>> >I wonder if there’s a difference between Flash and JS. The tests seem
>>to
>> >indicate that isNaN() is very efficient in JS. It might be an
>>interesting
>> >project to compare badly performing cases in Flash to their JS
>> >counterparts.
>> >
>> >BTW, I just ran into a case where booleans behave differently in JS
>>than
>> >AS where initialization would not help. I’ve started my document. I’ll
>> >add this case. Once the doc starts coming together I’ll share on the
>> >list. :-)
>> >
>> >Harbs
>> >
>> >> On Aug 3, 2017, at 3:59 PM, Josh Tynjala <jo...@gmail.com>
>>wrote:
>> >>
>> >> Switching away from isNaN() in Feathers improved performance in a
>> >> measurable way. It wasn't just a guess.
>> >>
>> >> - Josh
>> >>
>> >> On Aug 2, 2017 11:53 PM, "Harbs" <ha...@gmail.com> wrote:
>> >>
>> >> Ah. Thanks. (I haven’t had my coffee yet) ;-)
>> >>
>> >> It would be interesting to know if that really is more efficient.
>> >>
>> >>> On Aug 3, 2017, at 9:33 AM, Greg Dove <gr...@gmail.com> wrote:
>> >>>
>> >>> I assume it is if (unknownNumOrNaN != unknownNumOrNaN )
>> >>>
>> >>> I have used things like if (unknownNumOrNaN *0 !=0) in the past but
>>the
>> >>> above seems better
>> >>>
>> >>>
>> >>> On Thu, Aug 3, 2017 at 6:20 PM, Harbs <ha...@gmail.com> wrote:
>> >>>
>> >>>> I’m curious. How does that work?
>> >>>> unknownNumOrNaN != NaN will always be true
>> >>>>
>> >>>>> On Aug 3, 2017, at 1:37 AM, Josh Tynjala <jo...@gmail.com>
>> >>>>>wrote:
>> >>>>>
>> >>>>> Good one! To avoid the overhead of the isNaN() function call, I
>> >>>> frequently
>> >>>>> rely on the fact that NaN != NaN.
>> >>>>>
>> >>>>> - Josh
>> >>>>>
>> >>>>> On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com>
>>wrote:
>> >>>>>
>> >>>>>> Thanks for the history lesson. :-)
>> >>>>>>
>> >>>>>> This does bring up another difference between an initialized
>>value
>> >>>>>>of
>> >>>> NaN
>> >>>>>> and undefined:
>> >>>>>>
>> >>>>>> NaN != NaN, while undefined == undefined
>> >>>>>>
>> >>>>>>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net>
>> >>>>>>>wrote:
>> >>>>>>>
>> >>>>>>> I hate this Macbook’s touch top bar which puts a send button
>> >>>>>>>directly
>> >>>>>> above the delete key.
>> >>>>>>>
>> >>>>>>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net>
>> >>>> wrote:
>> >>>>>>>>
>> >>>>>>>> Hi Folks,
>> >>>>>>>>
>> >>>>>>>> A peanut gallery look at NaN which is really a bit encoding for
>> >>>> various
>> >>>>>> kinds of floating point number errors like underflow, overflow,
>> >>>>>>divided
>> >>>> by
>> >>>>>> 0, etc. In my Fortran past life we used XMISS as a special valu
>> >>>>>>>
>> >>>>>>> Value. Essentially undefined.
>> >>>>>>>
>> >>>>>>> IEEE had very particular definitions and Apple published a book
>> >>>>>>>about
>> >>>>>> SANE.
>> >>>>>>>
>> >>>>>>> At any rate what you guys are observing is by design: NaN always
>> >>>> results
>> >>>>>> in false in any comparison. And it is a number. But it is not a
>> >>>>>>number
>> >>>> in
>> >>>>>> floating point so much as it is an error condition.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fsta
>> >>>>>>>ckoverflow.com%2Fquestions%2F1565164%2Fwhat-
>> is-the-&data=02%7C01%7C%
>> >>>>>>>7Cf21eaebf1ebe4106701408d4da73e58d%7Cfa7b1b5a7b34438794aed2c178de
>> cee
>> >>>>>>>1%7C0%7C0%7C636373638698893388&sdata=y0%
>> 2BkjVQhq9ALdDR5QSKUVtzmggB66
>> >>>>>>>8usWbRnc9fZFC8%3D&reserved=0
>> >>>>>> rationale-for-all-comparisons-returning-false-for-ieee754-
>> nan-values
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>https://na01.safelinks.protection.outlook.com/?url=
>> https:%2F%2Fpeopl
>> >>>>>>>e.eecs.berkeley.edu%2F~wkahan%2Fieee754status%
>> 2FIEEE754.PDF&data=02%
>> >>>>>>>7C01%7C%7Cf21eaebf1ebe4106701408d4da73
>> e58d%7Cfa7b1b5a7b34438794aed2c
>> >>>>>>>178decee1%7C0%7C1%7C636373638698893388&sdata=
>> ZNxIS0ccBrtUNO%2B4hto7a
>> >>>>>>>e425rLH2x1H0MDK7uA5pio%3D&reserved=0
>> >>>>>>>
>> >>>>>>> My father complained about when the IBM 360 came out in the
>>early
>> >>>> 1960’s
>> >>>>>> he had to go to doubles because the IBM architecture went from 6
>>- 6
>> >> bit
>> >>>>>> words for a single to 4 - 8 bit words. The practical result was
>> >>>>>>twice
>> >> as
>> >>>>>> much magnetic tape both length and number of reals.
>> >>>>>>>
>> >>>>>>> Regards,
>> >>>>>>> Dave
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com>
>> >>>>>>>>>wrote:
>> >>>>>>>>>
>> >>>>>>>>> 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 <ha...@gmail.com>
>> >>>> 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 <gr...@gmail.com>
>> >>>>>>>>>>>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)
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >
>>
>>
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.
Posted by Josh Tynjala <jo...@gmail.com>.
It seems dangerous to replace isNaN with someNumber !== someNumber. In that
article, they said that isNaN() could return false positives, but I don't
actually consider their example to be a false positive at all. I would
fully expect isNaN() to return true for a string value. If we replaced that
example call to isNaN() with !==, and the result became false instead of
true, I would consider it a bug.
In Flash/AIR, isNaN() accepts only type Number. In the JS typedefs, isNaN()
accepts anything. I guess if the type of the variable is known to be
Number, the compiler could switch to !==. If it's a different type, we
should probably keep using isNaN(). For some types, we may even be able to
assume that isNaN() will always return true. However, we need to be careful
about edge cases. A Number could be stored in type Object, for instance.
- Josh
On Thu, Aug 3, 2017 at 7:22 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
> Here's an article about isNaN is JS.
>
> http://adripofjavascript.com/blog/drips/the-problem-with-
> testing-for-nan-in
> -javascript.html
>
> Maybe the transpiler should not output isNaN and instead "someNumber !==
> someNumber"
>
> -Alex
>
> On 8/3/17, 6:30 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >Cool.
> >
> >I wonder if there’s a difference between Flash and JS. The tests seem to
> >indicate that isNaN() is very efficient in JS. It might be an interesting
> >project to compare badly performing cases in Flash to their JS
> >counterparts.
> >
> >BTW, I just ran into a case where booleans behave differently in JS than
> >AS where initialization would not help. I’ve started my document. I’ll
> >add this case. Once the doc starts coming together I’ll share on the
> >list. :-)
> >
> >Harbs
> >
> >> On Aug 3, 2017, at 3:59 PM, Josh Tynjala <jo...@gmail.com> wrote:
> >>
> >> Switching away from isNaN() in Feathers improved performance in a
> >> measurable way. It wasn't just a guess.
> >>
> >> - Josh
> >>
> >> On Aug 2, 2017 11:53 PM, "Harbs" <ha...@gmail.com> wrote:
> >>
> >> Ah. Thanks. (I haven’t had my coffee yet) ;-)
> >>
> >> It would be interesting to know if that really is more efficient.
> >>
> >>> On Aug 3, 2017, at 9:33 AM, Greg Dove <gr...@gmail.com> wrote:
> >>>
> >>> I assume it is if (unknownNumOrNaN != unknownNumOrNaN )
> >>>
> >>> I have used things like if (unknownNumOrNaN *0 !=0) in the past but the
> >>> above seems better
> >>>
> >>>
> >>> On Thu, Aug 3, 2017 at 6:20 PM, Harbs <ha...@gmail.com> wrote:
> >>>
> >>>> I’m curious. How does that work?
> >>>> unknownNumOrNaN != NaN will always be true
> >>>>
> >>>>> On Aug 3, 2017, at 1:37 AM, Josh Tynjala <jo...@gmail.com>
> >>>>>wrote:
> >>>>>
> >>>>> Good one! To avoid the overhead of the isNaN() function call, I
> >>>> frequently
> >>>>> rely on the fact that NaN != NaN.
> >>>>>
> >>>>> - Josh
> >>>>>
> >>>>> On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com> wrote:
> >>>>>
> >>>>>> Thanks for the history lesson. :-)
> >>>>>>
> >>>>>> This does bring up another difference between an initialized value
> >>>>>>of
> >>>> NaN
> >>>>>> and undefined:
> >>>>>>
> >>>>>> NaN != NaN, while undefined == undefined
> >>>>>>
> >>>>>>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net>
> >>>>>>>wrote:
> >>>>>>>
> >>>>>>> I hate this Macbook’s touch top bar which puts a send button
> >>>>>>>directly
> >>>>>> above the delete key.
> >>>>>>>
> >>>>>>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi Folks,
> >>>>>>>>
> >>>>>>>> A peanut gallery look at NaN which is really a bit encoding for
> >>>> various
> >>>>>> kinds of floating point number errors like underflow, overflow,
> >>>>>>divided
> >>>> by
> >>>>>> 0, etc. In my Fortran past life we used XMISS as a special valu
> >>>>>>>
> >>>>>>> Value. Essentially undefined.
> >>>>>>>
> >>>>>>> IEEE had very particular definitions and Apple published a book
> >>>>>>>about
> >>>>>> SANE.
> >>>>>>>
> >>>>>>> At any rate what you guys are observing is by design: NaN always
> >>>> results
> >>>>>> in false in any comparison. And it is a number. But it is not a
> >>>>>>number
> >>>> in
> >>>>>> floating point so much as it is an error condition.
> >>>>>>>
> >>>>>>>
> >>>>>>>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsta
> >>>>>>>ckoverflow.com%2Fquestions%2F1565164%2Fwhat-
> is-the-&data=02%7C01%7C%
> >>>>>>>7Cf21eaebf1ebe4106701408d4da73e58d%7Cfa7b1b5a7b34438794aed2c178de
> cee
> >>>>>>>1%7C0%7C0%7C636373638698893388&sdata=y0%
> 2BkjVQhq9ALdDR5QSKUVtzmggB66
> >>>>>>>8usWbRnc9fZFC8%3D&reserved=0
> >>>>>> rationale-for-all-comparisons-returning-false-for-ieee754-
> nan-values
> >>>>>>>
> >>>>>>>
> >>>>>>>https://na01.safelinks.protection.outlook.com/?url=
> https:%2F%2Fpeopl
> >>>>>>>e.eecs.berkeley.edu%2F~wkahan%2Fieee754status%
> 2FIEEE754.PDF&data=02%
> >>>>>>>7C01%7C%7Cf21eaebf1ebe4106701408d4da73
> e58d%7Cfa7b1b5a7b34438794aed2c
> >>>>>>>178decee1%7C0%7C1%7C636373638698893388&sdata=
> ZNxIS0ccBrtUNO%2B4hto7a
> >>>>>>>e425rLH2x1H0MDK7uA5pio%3D&reserved=0
> >>>>>>>
> >>>>>>> My father complained about when the IBM 360 came out in the early
> >>>> 1960’s
> >>>>>> he had to go to doubles because the IBM architecture went from 6 - 6
> >> bit
> >>>>>> words for a single to 4 - 8 bit words. The practical result was
> >>>>>>twice
> >> as
> >>>>>> much magnetic tape both length and number of reals.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Dave
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com>
> >>>>>>>>>wrote:
> >>>>>>>>>
> >>>>>>>>> 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 <ha...@gmail.com>
> >>>> 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 <gr...@gmail.com>
> >>>>>>>>>>>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)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >
>
>
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.
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Here's an article about isNaN is JS.
http://adripofjavascript.com/blog/drips/the-problem-with-testing-for-nan-in
-javascript.html
Maybe the transpiler should not output isNaN and instead "someNumber !==
someNumber"
-Alex
On 8/3/17, 6:30 AM, "Harbs" <ha...@gmail.com> wrote:
>Cool.
>
>I wonder if there’s a difference between Flash and JS. The tests seem to
>indicate that isNaN() is very efficient in JS. It might be an interesting
>project to compare badly performing cases in Flash to their JS
>counterparts.
>
>BTW, I just ran into a case where booleans behave differently in JS than
>AS where initialization would not help. I’ve started my document. I’ll
>add this case. Once the doc starts coming together I’ll share on the
>list. :-)
>
>Harbs
>
>> On Aug 3, 2017, at 3:59 PM, Josh Tynjala <jo...@gmail.com> wrote:
>>
>> Switching away from isNaN() in Feathers improved performance in a
>> measurable way. It wasn't just a guess.
>>
>> - Josh
>>
>> On Aug 2, 2017 11:53 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> Ah. Thanks. (I haven’t had my coffee yet) ;-)
>>
>> It would be interesting to know if that really is more efficient.
>>
>>> On Aug 3, 2017, at 9:33 AM, Greg Dove <gr...@gmail.com> wrote:
>>>
>>> I assume it is if (unknownNumOrNaN != unknownNumOrNaN )
>>>
>>> I have used things like if (unknownNumOrNaN *0 !=0) in the past but the
>>> above seems better
>>>
>>>
>>> On Thu, Aug 3, 2017 at 6:20 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>>> I’m curious. How does that work?
>>>> unknownNumOrNaN != NaN will always be true
>>>>
>>>>> On Aug 3, 2017, at 1:37 AM, Josh Tynjala <jo...@gmail.com>
>>>>>wrote:
>>>>>
>>>>> Good one! To avoid the overhead of the isNaN() function call, I
>>>> frequently
>>>>> rely on the fact that NaN != NaN.
>>>>>
>>>>> - Josh
>>>>>
>>>>> On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com> wrote:
>>>>>
>>>>>> Thanks for the history lesson. :-)
>>>>>>
>>>>>> This does bring up another difference between an initialized value
>>>>>>of
>>>> NaN
>>>>>> and undefined:
>>>>>>
>>>>>> NaN != NaN, while undefined == undefined
>>>>>>
>>>>>>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net>
>>>>>>>wrote:
>>>>>>>
>>>>>>> I hate this Macbook’s touch top bar which puts a send button
>>>>>>>directly
>>>>>> above the delete key.
>>>>>>>
>>>>>>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net>
>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Folks,
>>>>>>>>
>>>>>>>> A peanut gallery look at NaN which is really a bit encoding for
>>>> various
>>>>>> kinds of floating point number errors like underflow, overflow,
>>>>>>divided
>>>> by
>>>>>> 0, etc. In my Fortran past life we used XMISS as a special valu
>>>>>>>
>>>>>>> Value. Essentially undefined.
>>>>>>>
>>>>>>> IEEE had very particular definitions and Apple published a book
>>>>>>>about
>>>>>> SANE.
>>>>>>>
>>>>>>> At any rate what you guys are observing is by design: NaN always
>>>> results
>>>>>> in false in any comparison. And it is a number. But it is not a
>>>>>>number
>>>> in
>>>>>> floating point so much as it is an error condition.
>>>>>>>
>>>>>>>
>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
>>>>>>>ckoverflow.com%2Fquestions%2F1565164%2Fwhat-is-the-&data=02%7C01%7C%
>>>>>>>7Cf21eaebf1ebe4106701408d4da73e58d%7Cfa7b1b5a7b34438794aed2c178decee
>>>>>>>1%7C0%7C0%7C636373638698893388&sdata=y0%2BkjVQhq9ALdDR5QSKUVtzmggB66
>>>>>>>8usWbRnc9fZFC8%3D&reserved=0
>>>>>> rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
>>>>>>>
>>>>>>>
>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fpeopl
>>>>>>>e.eecs.berkeley.edu%2F~wkahan%2Fieee754status%2FIEEE754.PDF&data=02%
>>>>>>>7C01%7C%7Cf21eaebf1ebe4106701408d4da73e58d%7Cfa7b1b5a7b34438794aed2c
>>>>>>>178decee1%7C0%7C1%7C636373638698893388&sdata=ZNxIS0ccBrtUNO%2B4hto7a
>>>>>>>e425rLH2x1H0MDK7uA5pio%3D&reserved=0
>>>>>>>
>>>>>>> My father complained about when the IBM 360 came out in the early
>>>> 1960’s
>>>>>> he had to go to doubles because the IBM architecture went from 6 - 6
>> bit
>>>>>> words for a single to 4 - 8 bit words. The practical result was
>>>>>>twice
>> as
>>>>>> much magnetic tape both length and number of reals.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Dave
>>>>>>>
>>>>>>>>
>>>>>>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com>
>>>>>>>>>wrote:
>>>>>>>>>
>>>>>>>>> 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 <ha...@gmail.com>
>>>> 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 <gr...@gmail.com>
>>>>>>>>>>>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)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>
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.
Posted by Harbs <ha...@gmail.com>.
It seems that there is:
https://jsperf.com/isnan-performance/2 <https://jsperf.com/isnan-performance/2>
I did not see much difference between methods in terms of performance.
> On Aug 3, 2017, at 4:30 PM, Harbs <ha...@gmail.com> wrote:
>
> I wonder if there’s a difference between Flash and JS.
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.
Posted by Harbs <ha...@gmail.com>.
Cool.
I wonder if there’s a difference between Flash and JS. The tests seem to indicate that isNaN() is very efficient in JS. It might be an interesting project to compare badly performing cases in Flash to their JS counterparts.
BTW, I just ran into a case where booleans behave differently in JS than AS where initialization would not help. I’ve started my document. I’ll add this case. Once the doc starts coming together I’ll share on the list. :-)
Harbs
> On Aug 3, 2017, at 3:59 PM, Josh Tynjala <jo...@gmail.com> wrote:
>
> Switching away from isNaN() in Feathers improved performance in a
> measurable way. It wasn't just a guess.
>
> - Josh
>
> On Aug 2, 2017 11:53 PM, "Harbs" <ha...@gmail.com> wrote:
>
> Ah. Thanks. (I haven’t had my coffee yet) ;-)
>
> It would be interesting to know if that really is more efficient.
>
>> On Aug 3, 2017, at 9:33 AM, Greg Dove <gr...@gmail.com> wrote:
>>
>> I assume it is if (unknownNumOrNaN != unknownNumOrNaN )
>>
>> I have used things like if (unknownNumOrNaN *0 !=0) in the past but the
>> above seems better
>>
>>
>> On Thu, Aug 3, 2017 at 6:20 PM, Harbs <ha...@gmail.com> wrote:
>>
>>> I’m curious. How does that work?
>>> unknownNumOrNaN != NaN will always be true
>>>
>>>> On Aug 3, 2017, at 1:37 AM, Josh Tynjala <jo...@gmail.com> wrote:
>>>>
>>>> Good one! To avoid the overhead of the isNaN() function call, I
>>> frequently
>>>> rely on the fact that NaN != NaN.
>>>>
>>>> - Josh
>>>>
>>>> On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com> wrote:
>>>>
>>>>> Thanks for the history lesson. :-)
>>>>>
>>>>> This does bring up another difference between an initialized value of
>>> NaN
>>>>> and undefined:
>>>>>
>>>>> NaN != NaN, while undefined == undefined
>>>>>
>>>>>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net> wrote:
>>>>>>
>>>>>> I hate this Macbook’s touch top bar which puts a send button directly
>>>>> above the delete key.
>>>>>>
>>>>>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net>
>>> wrote:
>>>>>>>
>>>>>>> Hi Folks,
>>>>>>>
>>>>>>> A peanut gallery look at NaN which is really a bit encoding for
>>> various
>>>>> kinds of floating point number errors like underflow, overflow, divided
>>> by
>>>>> 0, etc. In my Fortran past life we used XMISS as a special valu
>>>>>>
>>>>>> Value. Essentially undefined.
>>>>>>
>>>>>> IEEE had very particular definitions and Apple published a book about
>>>>> SANE.
>>>>>>
>>>>>> At any rate what you guys are observing is by design: NaN always
>>> results
>>>>> in false in any comparison. And it is a number. But it is not a number
>>> in
>>>>> floating point so much as it is an error condition.
>>>>>>
>>>>>> https://stackoverflow.com/questions/1565164/what-is-the-
>>>>> rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
>>>>>>
>>>>>> https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>>>>>>
>>>>>> My father complained about when the IBM 360 came out in the early
>>> 1960’s
>>>>> he had to go to doubles because the IBM architecture went from 6 - 6
> bit
>>>>> words for a single to 4 - 8 bit words. The practical result was twice
> as
>>>>> much magnetic tape both length and number of reals.
>>>>>>
>>>>>> Regards,
>>>>>> Dave
>>>>>>
>>>>>>>
>>>>>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> 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 <ha...@gmail.com>
>>> 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 <gr...@gmail.com> 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)
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
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.
Posted by Josh Tynjala <jo...@gmail.com>.
Switching away from isNaN() in Feathers improved performance in a
measurable way. It wasn't just a guess.
- Josh
On Aug 2, 2017 11:53 PM, "Harbs" <ha...@gmail.com> wrote:
Ah. Thanks. (I haven’t had my coffee yet) ;-)
It would be interesting to know if that really is more efficient.
> On Aug 3, 2017, at 9:33 AM, Greg Dove <gr...@gmail.com> wrote:
>
> I assume it is if (unknownNumOrNaN != unknownNumOrNaN )
>
> I have used things like if (unknownNumOrNaN *0 !=0) in the past but the
> above seems better
>
>
> On Thu, Aug 3, 2017 at 6:20 PM, Harbs <ha...@gmail.com> wrote:
>
>> I’m curious. How does that work?
>> unknownNumOrNaN != NaN will always be true
>>
>>> On Aug 3, 2017, at 1:37 AM, Josh Tynjala <jo...@gmail.com> wrote:
>>>
>>> Good one! To avoid the overhead of the isNaN() function call, I
>> frequently
>>> rely on the fact that NaN != NaN.
>>>
>>> - Josh
>>>
>>> On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>>> Thanks for the history lesson. :-)
>>>>
>>>> This does bring up another difference between an initialized value of
>> NaN
>>>> and undefined:
>>>>
>>>> NaN != NaN, while undefined == undefined
>>>>
>>>>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net> wrote:
>>>>>
>>>>> I hate this Macbook’s touch top bar which puts a send button directly
>>>> above the delete key.
>>>>>
>>>>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net>
>> wrote:
>>>>>>
>>>>>> Hi Folks,
>>>>>>
>>>>>> A peanut gallery look at NaN which is really a bit encoding for
>> various
>>>> kinds of floating point number errors like underflow, overflow, divided
>> by
>>>> 0, etc. In my Fortran past life we used XMISS as a special valu
>>>>>
>>>>> Value. Essentially undefined.
>>>>>
>>>>> IEEE had very particular definitions and Apple published a book about
>>>> SANE.
>>>>>
>>>>> At any rate what you guys are observing is by design: NaN always
>> results
>>>> in false in any comparison. And it is a number. But it is not a number
>> in
>>>> floating point so much as it is an error condition.
>>>>>
>>>>> https://stackoverflow.com/questions/1565164/what-is-the-
>>>> rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
>>>>>
>>>>> https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>>>>>
>>>>> My father complained about when the IBM 360 came out in the early
>> 1960’s
>>>> he had to go to doubles because the IBM architecture went from 6 - 6
bit
>>>> words for a single to 4 - 8 bit words. The practical result was twice
as
>>>> much magnetic tape both length and number of reals.
>>>>>
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>>>
>>>>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
>>>>>>>
>>>>>>> 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 <ha...@gmail.com>
>> 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 <gr...@gmail.com> 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)
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
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.
Posted by Harbs <ha...@gmail.com>.
Ah. Thanks. (I haven’t had my coffee yet) ;-)
It would be interesting to know if that really is more efficient.
> On Aug 3, 2017, at 9:33 AM, Greg Dove <gr...@gmail.com> wrote:
>
> I assume it is if (unknownNumOrNaN != unknownNumOrNaN )
>
> I have used things like if (unknownNumOrNaN *0 !=0) in the past but the
> above seems better
>
>
> On Thu, Aug 3, 2017 at 6:20 PM, Harbs <ha...@gmail.com> wrote:
>
>> I’m curious. How does that work?
>> unknownNumOrNaN != NaN will always be true
>>
>>> On Aug 3, 2017, at 1:37 AM, Josh Tynjala <jo...@gmail.com> wrote:
>>>
>>> Good one! To avoid the overhead of the isNaN() function call, I
>> frequently
>>> rely on the fact that NaN != NaN.
>>>
>>> - Josh
>>>
>>> On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>>> Thanks for the history lesson. :-)
>>>>
>>>> This does bring up another difference between an initialized value of
>> NaN
>>>> and undefined:
>>>>
>>>> NaN != NaN, while undefined == undefined
>>>>
>>>>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net> wrote:
>>>>>
>>>>> I hate this Macbook’s touch top bar which puts a send button directly
>>>> above the delete key.
>>>>>
>>>>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net>
>> wrote:
>>>>>>
>>>>>> Hi Folks,
>>>>>>
>>>>>> A peanut gallery look at NaN which is really a bit encoding for
>> various
>>>> kinds of floating point number errors like underflow, overflow, divided
>> by
>>>> 0, etc. In my Fortran past life we used XMISS as a special valu
>>>>>
>>>>> Value. Essentially undefined.
>>>>>
>>>>> IEEE had very particular definitions and Apple published a book about
>>>> SANE.
>>>>>
>>>>> At any rate what you guys are observing is by design: NaN always
>> results
>>>> in false in any comparison. And it is a number. But it is not a number
>> in
>>>> floating point so much as it is an error condition.
>>>>>
>>>>> https://stackoverflow.com/questions/1565164/what-is-the-
>>>> rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
>>>>>
>>>>> https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>>>>>
>>>>> My father complained about when the IBM 360 came out in the early
>> 1960’s
>>>> he had to go to doubles because the IBM architecture went from 6 - 6 bit
>>>> words for a single to 4 - 8 bit words. The practical result was twice as
>>>> much magnetic tape both length and number of reals.
>>>>>
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>>>
>>>>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
>>>>>>>
>>>>>>> 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 <ha...@gmail.com>
>> 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 <gr...@gmail.com> 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)
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
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.
Posted by Greg Dove <gr...@gmail.com>.
I assume it is if (unknownNumOrNaN != unknownNumOrNaN )
I have used things like if (unknownNumOrNaN *0 !=0) in the past but the
above seems better
On Thu, Aug 3, 2017 at 6:20 PM, Harbs <ha...@gmail.com> wrote:
> I’m curious. How does that work?
> unknownNumOrNaN != NaN will always be true
>
> > On Aug 3, 2017, at 1:37 AM, Josh Tynjala <jo...@gmail.com> wrote:
> >
> > Good one! To avoid the overhead of the isNaN() function call, I
> frequently
> > rely on the fact that NaN != NaN.
> >
> > - Josh
> >
> > On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com> wrote:
> >
> >> Thanks for the history lesson. :-)
> >>
> >> This does bring up another difference between an initialized value of
> NaN
> >> and undefined:
> >>
> >> NaN != NaN, while undefined == undefined
> >>
> >>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net> wrote:
> >>>
> >>> I hate this Macbook’s touch top bar which puts a send button directly
> >> above the delete key.
> >>>
> >>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net>
> wrote:
> >>>>
> >>>> Hi Folks,
> >>>>
> >>>> A peanut gallery look at NaN which is really a bit encoding for
> various
> >> kinds of floating point number errors like underflow, overflow, divided
> by
> >> 0, etc. In my Fortran past life we used XMISS as a special valu
> >>>
> >>> Value. Essentially undefined.
> >>>
> >>> IEEE had very particular definitions and Apple published a book about
> >> SANE.
> >>>
> >>> At any rate what you guys are observing is by design: NaN always
> results
> >> in false in any comparison. And it is a number. But it is not a number
> in
> >> floating point so much as it is an error condition.
> >>>
> >>> https://stackoverflow.com/questions/1565164/what-is-the-
> >> rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
> >>>
> >>> https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
> >>>
> >>> My father complained about when the IBM 360 came out in the early
> 1960’s
> >> he had to go to doubles because the IBM architecture went from 6 - 6 bit
> >> words for a single to 4 - 8 bit words. The practical result was twice as
> >> much magnetic tape both length and number of reals.
> >>>
> >>> Regards,
> >>> Dave
> >>>
> >>>>
> >>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
> >>>>>
> >>>>> 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 <ha...@gmail.com>
> 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 <gr...@gmail.com> 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)
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> >>
>
>
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.
Posted by Harbs <ha...@gmail.com>.
I’m curious. How does that work?
unknownNumOrNaN != NaN will always be true
> On Aug 3, 2017, at 1:37 AM, Josh Tynjala <jo...@gmail.com> wrote:
>
> Good one! To avoid the overhead of the isNaN() function call, I frequently
> rely on the fact that NaN != NaN.
>
> - Josh
>
> On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com> wrote:
>
>> Thanks for the history lesson. :-)
>>
>> This does bring up another difference between an initialized value of NaN
>> and undefined:
>>
>> NaN != NaN, while undefined == undefined
>>
>>> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net> wrote:
>>>
>>> I hate this Macbook’s touch top bar which puts a send button directly
>> above the delete key.
>>>
>>>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net> wrote:
>>>>
>>>> Hi Folks,
>>>>
>>>> A peanut gallery look at NaN which is really a bit encoding for various
>> kinds of floating point number errors like underflow, overflow, divided by
>> 0, etc. In my Fortran past life we used XMISS as a special valu
>>>
>>> Value. Essentially undefined.
>>>
>>> IEEE had very particular definitions and Apple published a book about
>> SANE.
>>>
>>> At any rate what you guys are observing is by design: NaN always results
>> in false in any comparison. And it is a number. But it is not a number in
>> floating point so much as it is an error condition.
>>>
>>> https://stackoverflow.com/questions/1565164/what-is-the-
>> rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
>>>
>>> https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>>>
>>> My father complained about when the IBM 360 came out in the early 1960’s
>> he had to go to doubles because the IBM architecture went from 6 - 6 bit
>> words for a single to 4 - 8 bit words. The practical result was twice as
>> much magnetic tape both length and number of reals.
>>>
>>> Regards,
>>> Dave
>>>
>>>>
>>>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
>>>>>
>>>>> 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 <ha...@gmail.com> 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 <gr...@gmail.com> 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)
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
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.
Posted by Josh Tynjala <jo...@gmail.com>.
Good one! To avoid the overhead of the isNaN() function call, I frequently
rely on the fact that NaN != NaN.
- Josh
On Wed, Aug 2, 2017 at 3:32 PM, Harbs <ha...@gmail.com> wrote:
> Thanks for the history lesson. :-)
>
> This does bring up another difference between an initialized value of NaN
> and undefined:
>
> NaN != NaN, while undefined == undefined
>
> > On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net> wrote:
> >
> > I hate this Macbook’s touch top bar which puts a send button directly
> above the delete key.
> >
> >> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net> wrote:
> >>
> >> Hi Folks,
> >>
> >> A peanut gallery look at NaN which is really a bit encoding for various
> kinds of floating point number errors like underflow, overflow, divided by
> 0, etc. In my Fortran past life we used XMISS as a special valu
> >
> > Value. Essentially undefined.
> >
> > IEEE had very particular definitions and Apple published a book about
> SANE.
> >
> > At any rate what you guys are observing is by design: NaN always results
> in false in any comparison. And it is a number. But it is not a number in
> floating point so much as it is an error condition.
> >
> > https://stackoverflow.com/questions/1565164/what-is-the-
> rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
> >
> > https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
> >
> > My father complained about when the IBM 360 came out in the early 1960’s
> he had to go to doubles because the IBM architecture went from 6 - 6 bit
> words for a single to 4 - 8 bit words. The practical result was twice as
> much magnetic tape both length and number of reals.
> >
> > Regards,
> > Dave
> >
> >>
> >>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
> >>>
> >>> 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 <ha...@gmail.com> 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 <gr...@gmail.com> 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)
> >>>>
> >>>>
> >>
> >
>
>
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.
Posted by Harbs <ha...@gmail.com>.
Thanks for the history lesson. :-)
This does bring up another difference between an initialized value of NaN and undefined:
NaN != NaN, while undefined == undefined
> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net> wrote:
>
> I hate this Macbook’s touch top bar which puts a send button directly above the delete key.
>
>> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net> wrote:
>>
>> Hi Folks,
>>
>> A peanut gallery look at NaN which is really a bit encoding for various kinds of floating point number errors like underflow, overflow, divided by 0, etc. In my Fortran past life we used XMISS as a special valu
>
> Value. Essentially undefined.
>
> IEEE had very particular definitions and Apple published a book about SANE.
>
> At any rate what you guys are observing is by design: NaN always results in false in any comparison. And it is a number. But it is not a number in floating point so much as it is an error condition.
>
> https://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
>
> https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>
> My father complained about when the IBM 360 came out in the early 1960’s he had to go to doubles because the IBM architecture went from 6 - 6 bit words for a single to 4 - 8 bit words. The practical result was twice as much magnetic tape both length and number of reals.
>
> Regards,
> Dave
>
>>
>>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
>>>
>>> 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 <ha...@gmail.com> 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 <gr...@gmail.com> 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)
>>>>
>>>>
>>
>
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.
Posted by Harbs <ha...@gmail.com>.
https://jonnyjordan.com/blog/remove-send-email-button-off-macbook-2016-touch-bar-apple-mail/ <https://jonnyjordan.com/blog/remove-send-email-button-off-macbook-2016-touch-bar-apple-mail/>
> On Aug 3, 2017, at 1:00 AM, Dave Fisher <da...@comcast.net> wrote:
>
> I hate this Macbook’s touch top bar which puts a send button directly above the delete key.
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.
Posted by Dave Fisher <da...@comcast.net>.
I hate this Macbook’s touch top bar which puts a send button directly above the delete key.
> On Aug 2, 2017, at 2:50 PM, Dave Fisher <da...@comcast.net> wrote:
>
> Hi Folks,
>
> A peanut gallery look at NaN which is really a bit encoding for various kinds of floating point number errors like underflow, overflow, divided by 0, etc. In my Fortran past life we used XMISS as a special valu
Value. Essentially undefined.
IEEE had very particular definitions and Apple published a book about SANE.
At any rate what you guys are observing is by design: NaN always results in false in any comparison. And it is a number. But it is not a number in floating point so much as it is an error condition.
https://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false-for-ieee754-nan-values
https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
My father complained about when the IBM 360 came out in the early 1960’s he had to go to doubles because the IBM architecture went from 6 - 6 bit words for a single to 4 - 8 bit words. The practical result was twice as much magnetic tape both length and number of reals.
Regards,
Dave
>
>> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
>>
>> 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 <ha...@gmail.com> 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 <gr...@gmail.com> 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)
>>>
>>>
>
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.
Posted by Dave Fisher <da...@comcast.net>.
Hi Folks,
A peanut gallery look at NaN which is really a bit encoding for various kinds of floating point number errors like underflow, overflow, divided by 0, etc. In my Fortran past life we used XMISS as a special valu
> On Aug 1, 2017, at 3:21 PM, Greg Dove <gr...@gmail.com> wrote:
>
> 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 <ha...@gmail.com> 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 <gr...@gmail.com> 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)
>>
>>
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.
Posted by Greg Dove <gr...@gmail.com>.
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 <ha...@gmail.com> 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 <gr...@gmail.com> 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)
>
>
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.
Posted by Harbs <ha...@gmail.com>.
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 <gr...@gmail.com> 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)
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.
Posted by Greg Dove <gr...@gmail.com>.
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 <jo...@gmail.com> 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 <ha...@gmail.com> 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, joshtynjala@apache.org 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 <jo...@apache.org>
> > > Authored: Mon Jul 31 14:47:24 2017 -0700
> > > Committer: Josh Tynjala <jo...@apache.org>
> > > 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);
> > > + }
> > > + }
> > > + }
> > > }
> > > }
> > >
> > >
> >
> >
>
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.
Posted by Josh Tynjala <jo...@gmail.com>.
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 <ha...@gmail.com> 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, joshtynjala@apache.org 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 <jo...@apache.org>
> > Authored: Mon Jul 31 14:47:24 2017 -0700
> > Committer: Josh Tynjala <jo...@apache.org>
> > 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);
> > + }
> > + }
> > + }
> > }
> > }
> >
> >
>
>