Uh, isn't that a pretty large compatibility risk?

<input type='checkbox' onclick='doUntestedStuff(tihs.checked)'>

You're suddenly calling doUntestedStuff() where before it was harmlessly erroring.


On 10/29/2015 12:30 PM, Ron Waldon wrote:

Has anyone considering just making dot-property access return intermediate undefined or null values by default?

Not having to introduce new syntax would be a bonus. I'm trying to think of existing code that this would break and can't think of any good examples.

The only compatibility issue I have thought of so far is code that relies on an Error being thrown but also does not check the value:

```js
let value;
try { value = deep.deep.deep.prop; } catch (err) { /* ... */ }
// use value without even a basic truthy test
```

On Fri, 30 Oct 2015, 06:07 <[email protected] <mailto:[email protected]>> wrote:


    ---------- Forwarded message ----------
    From: Laurentiu Macovei <[email protected]
    <mailto:[email protected]>>
    To: Sander Deryckere <[email protected]
    <mailto:[email protected]>>
    Cc: "es-discuss@ <mailto:[email protected]>mozilla.org
    <mailto:[email protected]> list" <[email protected]
    <mailto:[email protected]>>
    Date: Thu, 29 Oct 2015 19:52:37 +0100
    Subject: Re: Re: Existential Operator / Null Propagation Operator

    Yes! I have updated my answer using markdown and also posted on
    the original issue of TypeScript. https
    <https://github.com/Microsoft/TypeScript/issues/16>://
    <https://github.com/Microsoft/TypeScript/issues/16>github.com
    <https://github.com/Microsoft/TypeScript/issues/16>/Microsoft/
    <https://github.com/Microsoft/TypeScript/issues/16>TypeScript
    <https://github.com/Microsoft/TypeScript/issues/16>/issues/16
    <https://github.com/Microsoft/TypeScript/issues/16>

    Is there a better place to propose it for `ES6`/`ES7` ?

    This would be amazing operator!! Especially for
    `ES6`/`ES7`/`TypeScript`

    ```js

    var error = a.b.c.d; //this would fail with error if a, b or c are
    null or undefined.

    var current = a && a.b && a.b.c && a.b.c.d; // the current messy
    way to handle this

    var currentBrackets = a && a['b'] && a['b']['c'] &&
    a['b']['c']['d']; //the current messy way to handle this

    var typeScript = a?.b?.c?.d; // The typescript way of handling the
    above mess with no errors

    var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of
    handling the above mess with no errors

    ```

    However I propose a more clear one - as not to confuse ? from the
    a ? b : c statements with a?.b statements:

    ```js

    var doubleDots = a..b..c..d; //this would be ideal to understand
    that you assume that if any of a, b, c is null or undefined the
    result will be null or undefined.

    var doubleDotsWithBrackets = a..['b']..['c']..['d'];

    ```

    For the bracket notation, I recommend two dots instead of a single
    one as it's consistent with the others when non brackets are used.
    Hence only the property name is static or dynamic via brackets.

    Two dots, means if its null or undefined stop processing further
    and assume the result of expression is null or undefined. (as d
    would be null or undefined).

    Two dots make it more clear, more visible and more space-wise so
    you understand what's going on.

    This is not messing with numbers too - as is not the same case e.g.

    ```js

    1..toString(); // works returning '1'

    var x = {};

    x.1 = {y: 'test' }; //fails currently

    x[1] = {y: 'test' }; //works currently

    var current = x[1].y; //works

    var missing= x[2].y; //throws exception

    var assume= x && x[2] && x[2].y; // works but very messy

    ```

    About numbers two options: Your call which one can be adopted, but
    I recommend first one for compatibility with existing rules!

    1. Should fail as it does now (`x.1.y` == `runtime error`)

    ```js

    var err = x..1..y; // should fail as well, since 1 is not a good
    property name, nor a number to call a method, since it's after x
    object.

    ```

    2. Should work since it understands that is not a number calling a
    property from `Number.prototype`

    ```js

    var err = x..1..y; // should work as well, resulting 'test' in
    this case

    var err = x..2..y; // should work as well, resulting undefined in
    this case

    ```

    With dynamic names:

    ```js

    var correct1 = x..[1]..y; //would work returning 'test'

    var correct2 = x..[2]..y; //would work returning undefined;

    ```

    What do you think folks?

    Best Regards,

    Laurenţiu Macovei




_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to