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.li...@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 <joshtynj...@gmail.com> wrote:
>>
>> I'm +1 on changing to null by default on objects and strings. I know this
>> will improve compatibility with real world ActionScript code that expects
>> 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" <jus...@classsoftware.com> wrote:
>>
>>> 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 missed
>>> the humour there.
>>>
>>> So given you don’t want to use strict equality and inequality how do you
>>> want to handle this? Does everyone agree with that not using them despite
>>> just about all modern JS advice is to use them?
>>>
>>> There is as alternative that will fix a lot of the performance issues (but
>>> 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. Are
>>> you OK for Objects and Strings to default to null as well?
>>>
>>> Re concerns re increased size it seem the closure compiler handles this
>>> 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. https://herringtondarkholme.github.io/2016/11/05/how-to-
>>> write-copy-paste-friendly-code/
>>> 2. https://issues.apache.org/jira/browse/FLEX-35330
>
