W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

[Bug 23532] Dealing with undefined

From: <bugzilla@jessica.w3.org>
Date: Wed, 23 Oct 2013 20:16:25 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23532-3890-qvON0w4kJS@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23532

--- Comment #19 from Boris Zbarsky <bzbarsky@mit.edu> ---
> With that in mind I think the original post describes the best way to express
> required arguments: if it's `undefined`, throw your `TypeError`.

My point is that I'll bet you $500 that doing this for setAttribute is not
web-compatible.  Certainly not for the second argument.  I would be all in
favor of doing this if it were not for this minor little detail.  Certainly if
we were designing this as a green-field system we'd want to do that.

On the other hand, throwing if the argument is omitted altogether _is_
web-compatible.

> I believe the following rules would work.

Erik, I don't think these rules cover the setAttribute case at all.  Do you
think you can compatibly change that case to throw if explicit undefined is
passed?  If not, you need different rules.

> From a TC39 perspective, we would say that, of course, you cannot invalidate
> any existing DOM API.

Clearly at least Domenic disagrees...  but yes, that would be the sane approach
to API design.

> The place to start is with new APIs.

That's not the proposal in this bug, sadly.  But yes, that would be much more
palatable to me as an implementor.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 23 October 2013 20:16:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC