Allen Wirfs-Brock wrote:
While I'm less than enthusiastic about explicitly provided undefined values
triggering default value usages, I don't think it is particularly harmful. I
think treating null equivalently would be.
Noted, but you have not responded to the argument, made by Sam
Tobin-Hochstadt based on Racket experience, Tab Atkins in Common Lisp,
and others, that failing to treat explicit undefined as a defaulting
trigger creates an anti-modular, combinatorial explosion when wrapping
and delegating. This is the sole reason undefined (or undefined and
null, separate issue) as defaulting trigger is proposed. Please respond
to it directly.
>
> f = (x, y=1, z=2) -> console.log(x, y, z)
> f(0, null, undefined)
>
> generates
>
> f = function(x, y, z) {
> if (y == null) {
> y = 1;
> }
> if (z == null) {
> z = 2;
> }
> return console.log(x, y, z);
> };
>
> f(0, null, void 0);
>
> We could certainly do worse than to pave this cowpath.
sure, for example, by having any falsy value trigger default value usage. But
just because there are worse things doesn't make the a good idea.
That's a reductio ad absurdum, nothing to do with why I wrote what I wrote.
We have a problem with || indeed. The question is whether the solution
should equate null and undefined. CoffeeScript chose the
conceal-the-difference path and it has users. The users who want null to
be distinct from undefined are neither CoffeeScript users, nor || users
(in their defaulting code). They must be doing === undefined test. That
is rare too (not quite as rare as passing null instead of undefined as
intentional default trigger in my experience).
What is your reason for preferring === undefined over == null, since we
have a dilemma and users often use an even looser (falsy, viz ||) test
than == null, but some use == null and others use === undefined, for the
defaulting trigger?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
