Consistency in The Negative Result Values Through Expansion of null's Role
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
> 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
> 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.
More information about the es-discuss