Data types of returned results in ECMAScript binding...

The big thing that held up the HTML DOM from going to recommendation at 
the last minute was the types of values returned by ECMAScript calls in 
(most) existing browser implementations, which had been counted as 
implementations, but were returning data types other than those in the 
specification.

The ECMAScript binding clearly states what types should be returned.  
Due to the lack of real interfaces, returning the wrong type is a 
more-subtle bug that will permit scripts to successfully make calls and 
check return values, but if the resulting values are operated on, then 
the script will break between implementations because Javascript 
operators treat values of different types differently at run time.

I think that automatic features need to be built into ECMAScript test 
suites that also check at least the return types.  Another thing 
guaranteed by the interfaces in other bindings but not in ECMAScript is 
the methods and properties on an object of a certain type returned by 
DOM.  For example, I have noticed that ECMAScript bindings sometimes 
leave out item and namedItem method on the attributes NamedNodeMap, 
overloading array indexing operators instead to provide that type of 
lookup.  We can argue later about whether users of the ECMAScript 
bindings should use some other way to lookup entries by name or number 
in the map.  But whichever way is correct, the test suite needs to test 
for the fundamental integrity of the objects themselves, which is 
guaranteed on other platforms by interfaces.  Otherwise, Level 2 HTML 
DOM was perhaps ready for release as interpreted by our new set of test 
suites, which would be a mistake, I think.

Ray Whitmer
rayw@netscape.com

Received on Friday, 25 May 2001 14:17:08 UTC