W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

Re: [selectors-api] NSResolver question: non-String returns

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 19 Mar 2008 14:28:02 +0100
Message-ID: <47E114E2.5040904@lachy.id.au>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: Web APIs WG <public-webapi@w3.org>

Boris Zbarsky wrote:
> I've been thinking about this some more, and the requirement that the 
> caller be able to tell apart the NSResolver returning a String and some 
> other object that has a toString() method is actually a bit of a pain. 
> For example, in Gecko a C++ caller into this API would just get back a 
> string object (basically the result of |returnValue + ""| or so). 
> Telling where this string came from would actually be pretty difficult 
> in this case.
> Things get even worse if you allow non-JS implementations of NSResolver, 
> because at that point the requirement doesn't even make sense.
> Is there a strong reason not to just stringify whatever the NSResolver 
> returns?

The current editor's draft already requires any object returned to be 
converted to a string, with the only special requirement being that null 
and undefined are converted to, or at least treated as empty strings.

Lachlan Hunt - Opera Software
Received on Wednesday, 19 March 2008 13:28:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC