Path: csiph.com!aioe.org!news.mb-net.net!open-news-network.org!.POSTED.p200300788f0f0301ae8112fffe10829f.dip0.t-ipconnect.de!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Testing the =?UTF-8?B?4oCcbnVsbOKAnQ==?= value (was: In-Band Escape Values) Date: Wed, 03 Jan 2018 02:22:23 +0100 Organization: PointedEars Software (PES) Lines: 69 Message-ID: <2416455.mvXUDI8C0e@PointedEars.de> References: Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit Injection-Info: gwaiyur.mb-net.net; posting-host="p200300788f0f0301ae8112fffe10829f.dip0.t-ipconnect.de:2003:78:8f0f:301:ae81:12ff:fe10:829f"; logging-data="22363"; mail-complaints-to="abuse@open-news-network.org" User-Agent: KNode/4.14.2 X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. 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. > »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: | | Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail