flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: git commit: [flex-asjs] [refs/heads/tlf] - Reverted strict equality
Date Sun, 25 Jun 2017 06:00:34 GMT
You didn't get warnings when mixing undefined with Number or String?
Maybe you should...


On 6/24/17, 1:11 PM, "Harbs" <harbs.lists@gmail.com> wrote:

>Here’s a possible counter-argument to what I just wrote:
>undefined can be a functional change to ActionScript code when adding to
>numbers and strings:
>var obj:Foo;
>trace(1 + undefined); NaN
>trace("hello " + undefined); //hello undefined
>trace(1 + obj); //1
>trace("hello " + obj); //hello null
>trace(1 + null); //1
>trace("hello " + null); //hello null
>However, I'm actually not sure that initializing Numbers is necessary.
>Leaving it as undefined is generally functionally equivalent to NaN:
>isNaN(undefined) //true
>isNaN(null) //false
>But initializing ints to null will generally get the same result as
>initializing them to 0…
>> On Jun 24, 2017, at 10:35 PM, Harbs <harbs.lists@gmail.com> wrote:
>> I have never seen real world ActionScript code which uses strict
>>equality for null.
>> The argument to use strict equality “because of modern js advice” is
>>not a reason to use it in ActionScript. The whole argument is to avoid
>>unexpected type conversions. If you are dealing with typed variables,
>>that is generally not an issue.
>> Justin raised a valid argument to initialize Booleans and Numbers. It
>>should not be taken any further than that.
>> Harbs
>>> On Jun 24, 2017, at 8:04 PM, Josh Tynjala <joshtynjala@gmail.com>
>>> I'm +1 on changing to null by default on objects and strings. I know
>>> will improve compatibility with real world ActionScript code that
>>> null. We can include these in the compiler option to default back to
>>> undefined, for anyone that prefers that behavior.
>>> - Josh
>>> On Jun 23, 2017 7:45 PM, "Justin Mclean" <justin@classsoftware.com>
>>>> Hi,
>>>>> Your link is actually arguing for use for non-strict equality…
>>>> I suggest you read the content at the link again [1] perhaps you
>>>> the humour there.
>>>> So given you don’t want to use strict equality and inequality how do
>>>> want to handle this? Does everyone agree with that not using them
>>>> just about all modern JS advice is to use them?
>>>> There is as alternative that will fix a lot of the performance issues
>>>> not all) and that is to default Boolean, Numbers, Object and Strings
>>>>to a
>>>> sensible default rather than undefined. I’ve already done the work for
>>>> Boolean and Numbers as not initialising these can causes other bugs.
>>>> you OK for Objects and Strings to default to null as well?
>>>> Re concerns re increased size it seem the closure compiler handles
>>>> well and there is little or no size difference in the optimised JS
>>>> produced. I’ve so far found it to be smaller by a fraction of a %.
>>>> I’ve also raised a JIRA re performance here. [2]
>>>> Thanks,
>>>> Justin
>>>> 1. 
>>>> write-copy-paste-friendly-code/
>>>> 2. 

View raw message