Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #34432 > unrolled thread

Testing the “null” value (was: In-Band Escape Values)

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Testing the “null” value (was: In-Band Escape Values) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-01-03 02:22 +0100
    Re: Testing the null value (was In-Band Escape Values) John G Harris <niam@jghnorth.org.uk.invalid> - 2018-01-04 10:32 +0000

#34432 — Testing the “null” value (was: In-Band Escape Values)

Stefan Ram wrote:

>   What I cannot follow is the idea of nearly everyone that
>   there is something wrong about »typeof null« being »"object"«.

When there were no strict comparison, it was harder to test whether a value 
referred to an object, because “typeof x”, with “x” representing the value, 
would be "object" regardless whether the value referred to an object or was 
“null”.  This required at least

  typeof x == "object" && x == null

to test for the “null” value.

Nowadays (since implementations of ECMAScript Ed. 3) we have the “===” and 
“!==” operators, so the issue is only one of backwards compatibility, as

  x === null

and

  x !== null

will not compile in earlier implementations.  The only workaround I know is 
using eval() to determine whether the operators are supported, which 
decreases the efficiency of code and does not run with “Content-Security-
Policy” without the value “script-src unsafe-eval” (default).
 
>   In programming, people sometimes seem to use what in this post
>   I call an "in-band escape value" (IBEV).

Yes, you are known to make up your own terminology and universe, however 
unnecessarily complicated and nonsensical it may be.
 
>   An in-band escape value formally has a certain type, while
>   semantically it does not have this type.

That is such a nonsense, it is not even wrong.
 
>   For example, »NaN« (»this.NaN«) is the in-band escape value
>   of the type »number«.

No, it is not.  The property “this.NaN” by specification only exists if 
“this” refers to the global object.

<http://PointedEars.de/es-matrix/?filter=NaN#features-table>

>   »undefined« is the general escape value for every value.

Not even wrong.
 
>   »null« is an in-band escape value for objects, so formally
>   its type is »object«, while semantically it means, "not an
>   object".

See above.

Also, “not an object” does not necessarily mean “null”: it can also mean a 
primitive value.

  /* true */
  typeof 42 != "object"
 
> [further misconceptions and fallacies]

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail

[toc] | [next] | [standalone]

#34444 — Re: Testing the null value (was In-Band Escape Values)

On Wed, 03 Jan 2018 02:22:23 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Stefan Ram wrote:

  <snip>
>>   In programming, people sometimes seem to use what in this post
>>   I call an "in-band escape value" (IBEV).
>
>Yes, you are known to make up your own terminology and universe, however 
>unnecessarily complicated and nonsensical it may be.

In-band signalling is what made phone phreaking possible. The
terminology is well established.


>>   An in-band escape value formally has a certain type, while
>>   semantically it does not have this type.
>
>That is such a nonsense, it is not even wrong.
  <snip>

Ah, a programmer who sends binary data down an asynchronous comms link
and complains loudly when it doesn't arrive safely. Perhaps there's a
reason for using base64 in e-mails. Perhaps there's a scientific
description of that reason.

  John

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web