flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Tynjala <joshtynj...@gmail.com>
Subject Re: git commit: [flex-asjs] [refs/heads/tlf] - Reverted strict equality
Date Sun, 25 Jun 2017 16:25:30 GMT
I have seen it in real world code. In fact, I personally use strict
equality in ActionScript most of the time.

- Josh

On Jun 24, 2017 12: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.


> On Jun 24, 2017, at 8:04 PM, Josh Tynjala <joshtynjala@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" <justin@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
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message