W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

hasFeature and ECMAScript

From: Thomas Much <thomas@snailshell.de>
Date: Thu, 12 Jul 2001 23:47:43 +0200
To: <www-dom@w3.org>
CC: Joseph Kesselman <keshlam@us.ibm.com>
Message-ID: <B773E78A.5BBD%thomas@snailshell.de>
am 12.07.2001 14:48 Uhr schrieb Joseph Kesselman unter keshlam@us.ibm.com:

> I'd say that's a binding issue -- "what does null mean in this binding"

null and undefined are two different values in ECMAScript, so this could be
somewhat dangerous (both values evaluate to boolean false, but if an
ECMAScript implementation checks against null, it will fail when undefined
is passed). Unspecified function parameters are always treated as undefined
whereas the null value has to be passed explicitely.

> There's a consistancy question. If we declare that undefined shall be taken
> as null here, we should probably do so throughout the API.

I would *not* recommend this for all places where null is mentioned. If a
return value can be null (e.g. from document.getElementById), don't extend
it to undefined to avoid ambiguity - let the script programmer definitely
know what return value can be expected.
But if null is an input parameter and it is not used to specify an empty
reference but an unspecified value, an ECMAScript programmer should be
allowed to pass undefined as well, because "undefined" is in ECMAScript
terms the common unspecified value.

bye, Thomas

-- 
http://www.muchsoft.com/inscript/
http://www.icab.de
Received on Thursday, 12 July 2001 17:47:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:49 GMT