Consistency in The Negative Result Values Through Expansion of null's Role

David Bruant bruant.d at gmail.com
Wed Aug 15 17:15:22 PDT 2012


Le 16/08/2012 01:31, Brendan Eich a écrit :
> David Bruant wrote:
>> Le 16/08/2012 00:35, Rick Waldron a écrit :
>>> On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen <erik.reppen at gmail.com
>>> <mailto:erik.reppen at gmail.com>> wrote:
>>>
>>>
>>>     Is consistent type return a heuristic carried over from more
>>>     strictly-typed paradigms or would it murder performance of the
>>>     native methods to do the logic required to return something like
>>>     null in these cases? In a dynamic language, why not focus on more
>>>     consistent return types across the board for an indicator that
>>>     you won't be getting particularly handy results?
>>>
>>>
>>> It would break the web.
>> I agree and would like to encourage you (Erik) to read the foreword
>> of my "ECMAScript regrets" project
>> https://github.com/DavidBruant/ECMAScript-regrets#foreword
>>
>> The only way forward to "fix" broken parts of JavaScript (like making
>> it more consistent) is to give up on JavaScript and create a new
>> language that compiles down to JavaScript. That's my opinion at least.
>
> There's another way: extend JS with fixed forms and hope the broken
> ones die eventually.
I agree, but "hope" hasn't given the web a lot so far unfortunately.

Also, it should work fine for syntax, but built-in libraries (like what
Erik wants to see fixed) seem to be a different story. For instance,
Number.isNaN is a fixed form, but I'm not sure it'll be enough to see
isNaN die.

> Both compile-to-JS and evolve-JS-to-be-better are happening, and the
> former informs the latter directly (=> and for-of from CoffeeScript
> are in ES6, e.g.). Both should, since JS is at this point a huge
> public good, like it or not.
I could not agree more.

David


More information about the es-discuss mailing list