[Bug 23532] Dealing with undefined

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23532

Allen Wirfs-Brock <allen@wirfs-brock.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allen@wirfs-brock.com

--- Comment #18 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Boris Zbarsky from comment #11)
> > Consensus was reached between representatives of all major implementors
> 
> With all due respect, the people representing SpiderMonkey there have
> nothing to do with the methods this bug is talking about changing.  In
> particular, they do not have any idea of what the compatibility constraints,
> if any, are.  So their consensus on the ES behavior doesn't mean much for
> the DOM, unfortunately.
> 

I don't think this is a fair statement WRT compatibility constrains. TC39
imposes severe compatibility constraints upon ourselves.  Our aspirational goal
is to never break any existing JS code.  We would never change the language or
the API of any ES built-in function in a way that would invalidate existing
uses of the function. When we find this goal impossible to achieve  we are very
careful to determine that any code that is broken is a extreme outlier.

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

In Comment #12 you said,
>This bug's proposal (comment 0) comes down to making a whole bunch of methods
>that currently do not throw in certain cases start throwing in those cases.

If that's correct, it's absurd. There is no way that could actually happen to
the web platform. 

There is nothing in ES6 that forces any changes to DOM APIs.   However, it will
be good for the long term health of the platform, if DOM APIs began to look
more like idiomatic JS APIs. The place to start is with new APIs.  My sense is
that much of the difficulty you are encountering is that you are trying to
apply a common set of conventions to both new APIs and your legacy APIs and
this just doesn't work well because many of the legacy APIs do not follow
idiomatic JS conventions.

What we do in TC39, in similar cases, is to simply bite the bullet and 
describe the legacy API accurately but without using ES6 conveniences (such as
default parameter values) that are inconsistent with the legacy. When all else
fails we simply describe then as if the parameter signature was (...args) and
provide an algorithic definition of the parameter processing.

Allen

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 23 October 2013 16:22:39 UTC