Discuss
  • why (null <= 0) is true?

why (null <= 0) is true?

# Frank Quan (13 years ago)

null == 0 // false null > 0 // false

null < 0 // false

null >= 0 // true

null <= 0 // true

The above expressions are weird compared to the all-false "undefined". Why doesn't the spec treat null like undefined?

# Brendan Eich (13 years ago)

Frank Quan wrote:

null == 0 // false null > 0 // false null < 0 // false

null >= 0 // true null <= 0 // true

The above expressions are weird compared to the all-false "undefined". Why doesn't the spec treat null like undefined?

This is not really a question whose answer can change (not by default, anyway). Perhaps some day with opt-in metaprogramming of operators within a lexical scope.

The spec was not made up first, then implemented. The first implementation, by me in Netscape 2 in 1995 done in 10 days, included user-testing on some developers who really wanted something broken for ==, and I foolishly gave it to them (and to everyone).

The difference you see above is not specifically due to null vs. undefined, rather to == vs. the relational operators. Relationals convert to Number (the spec's term for the IEEE double type reported by typeof as "number"), and null converts to 0:

js> +null

0

The broken Equality operators == and != are more complicated, but in this case they at least do not convert null at all, rather they notice that its type is Null (ECMA spec term) and not the same as the right-hand side, which is Number, and so (based on both types not being caught by earlier steps in 11.9.3) the result for == is always false, != always true.

The non-conversion of null in this case is actually good. Doesn't make up for all the broken-ness, though.

# Frank Quan (13 years ago)

Brendan, thank you for reply.

I mean in common understanding, "a>=b" always have the same result with "

a>b || a==b ".

But I noticed that in ES5/ES3, there are several cases breaking this rule.

See the following:

null == 0 // false null > 0 // false

null >= 0 // true

I was wondering if this is by design.

And, is it possible to have some change in future versions of ES?

2012/9/25 Brendan Eich <brendan at mozilla.com>

# David Bruant (13 years ago)

Le 25/09/2012 12:13, Frank Quan a écrit :

Hi, Brendan, thank you for reply.

I mean in common understanding, "a>=b" always have the same result with " a>b || a==b ".

Common understanding assumes a and b are numbers. I personally don't know if there is a common understanding of what 'true > "azerty"' could

mean.

But I noticed that in ES5/ES3, there are several cases breaking this rule.

See the following:

null == 0 // false null > 0 // false

null >= 0 // true

I was wondering if this is by design.

And, is it possible to have some change in future versions of ES?

Regrettably, no. As a complement to Brendan's response, I recommand you to read the following paragraph DavidBruant/ECMAScript-regrets#web-technologies-are-ugly-and-there-is-no-way-back Changing this in a future version of ECMAScript would "break the web" (break websites that rely on this broken behavior)

# Andrea Giammarchi (13 years ago)

OT: Really David ... you use a french keyboard too? I can't imagine me programming with an italian layout :D

I believe the question was about fixing or spec'ing the behavior which seems reasonable.

We already decided to break the web with all new syntax stuff and "use strict" directive so if ES7 will have null <= 0 false I don't see how this could break the web ... I mean, typeof is already broken in ES3 compared to ES5 and use strict, the fact that specs say that null == null and undefined and nothing else means that developers would expect that <= or >= whatever

that is not null or undefined to be false.

my 2 cents

# Jussi Kalliokoski (13 years ago)

On Tue, Sep 25, 2012 at 1:22 PM, David Bruant <bruant.d at gmail.com> wrote:

Le 25/09/2012 12:13, Frank Quan a écrit :

Hi, Brendan, thank you for reply.

I mean in common understanding, "a>=b" always have the same result with " a>b || a==b ". Common understanding assumes a and b are numbers. I personally don't know if there is a common understanding of what 'true > "azerty"' could mean.

Indeed. For the fun of it, I think that in the context of JS that means Number(true) < "azerty".charCodeAt(0).

# Jussi Kalliokoski (13 years ago)

Oh wait, sorry, that's not true, that only applies to String comparisons.

# Frank Quan (13 years ago)

i mean a set of rules should have its logic.

true > "azerty"' //false

true == "azerty"' //false true >= "azerty"' // if here is true . is no wonder ?

2012/9/25 David Bruant <bruant.d at gmail.com>

# David Bruant (13 years ago)

Le 25/09/2012 12:41, Andrea Giammarchi a écrit :

OT: Really David ... you use a french keyboard too?

guilty :-D

I can't imagine me programming with an italian layout :D

I think it's just a matter of habit. Regardless, I use WebStorm as text editor, I think most of my code is written thanks to autocompletion rather than by typing letters :-) Also since source code is a tree and not a string, I'm looking forward to the day tools like Waterbear [1] will become mainstream and keyboard will just be used to name variables/functions, choose constants and hint the autocomplete engine.

I believe the question was about fixing or spec'ing the behavior which seems reasonable.

We already decided to break the web with all new syntax stuff and "use strict" directive

This is not true. In theory, before ES5, maybe some people had the "use strict" string in some js files. But let's be honest, no one actually did. No one reported that their program broke because of the addition of strict mode. As I say in ECMAScript Regrets, changing the current semantics is not possible, however, it's still possible to improve the language by adding new construct like pragma directives or new syntax. In theory again, it could break programs, but that would be programs which relied on syntax errors to work properly. I would say it's reasonable to break such programs.

so if ES7 will have null <= 0 false I don't see how this could break the web ...

Maybe some webpages depend on null <= 0 to be true. It relatively easy to have a JSON array which you loop over and which elements are numbers or null and rely on null <= 0 to be true to work properly. We've seen more crazy assumptions.

David

[1] waterbearlang.com

# Brendan Eich (13 years ago)

David, thanks for responding.

To give Frank and everyone some hope, with sweet.js and value objects (including operators) under construction, I believe we could get to the point where == could be redefined by a macro to be saner, at the macro-user's opt-in discretion.

You'd still have lexically bound operator names from a module that denote the built-in special forms, so macros can bottom out in the operators we know today.

No promises, just a reasonable extrapolation that will require some time to prototype and user-test.