A Strong Mode for JavaScript

Post by tragic » Thu, Mar 12, 2015, 8:56 AM UTC

pygy_ wrote: post #30

leichtgewicht wrote: post #28

Earlier quoted context omitted.

I fail to see how it breaks anything? It is opt-in. Aside from that "use optimize" is indeed a better naming.

It is supposed to be backwards compatible. "use strong" try { foo = bar[maybeMissing] } catch { // only runs in strong mode } The above will take different code paths depending on whether your JS engine supports "strong" mode.

Post by reissbaker » Thu, Mar 12, 2015, 9:21 AM UTC

tragic wrote: post #31

pygy_ wrote: post #30

Earlier quoted context omitted.

It is supposed to be backwards compatible. "use strong" try { foo = bar[maybeMissing] } catch { // only runs in strong mode } The above will take different code paths depending on whether your JS engine supports "strong" mode.

That's a good spot. I suppose it's a lot easier to declare one's intention to create a backwards-compatible subset than to actually create one. Hope the V8 people are open to revisions on the details at least.

    "use strict";
    try {
      a = true;
    } catch(e) {
      // only runs in strict mode
    }

    try {
      JSON.parse("{}");
    } catch(e) {
      // only runs in browsers that don't support JSON.parse
    }

    try {
      [ 1, 2, 3 ].forEach(function(x) { /* ... */ });
    } catch(e) {
      // only runs in browsers that don't support forEach
    }

    const x = 10;
    // only runs in browsers that support const

Post by realharo » Thu, Mar 12, 2015, 9:47 AM UTC

SigmundA wrote: post #15

dustin1114 wrote: post #9

I think I like most of what this document proposes except for the following: In strong code, accessing objects (strong or not) throws on missing properties. New object properties have to be defined explicitly and cannot be removed from strong objects. To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, wi…

I agree and I come from a strongly typed background (.Net). It is extremely liberating and useful to just add properties to an object at any time, even ones I didn't create. Kind of like slapping a sticker on something for later reference, whereas a strong types object just explodes when apply you the sticker. I understand that there are performances issues to doing things this way, but it seems like you could have t…

Post by pygy_ » Thu, Mar 12, 2015, 10:50 AM UTC

reissbaker wrote: post #33

tragic wrote: post #31

Earlier quoted context omitted.

That's a good spot. I suppose it's a lot easier to declare one's intention to create a backwards-compatible subset than to actually create one. Hope the V8 people are open to revisions on the details at least.

This is true of strict mode as well, which shipped in ES5. "use strict"; try { a = true; } catch(e) { // only runs in strict mode } It's true of any mode switch that makes the language smaller. You shouldn't write non-strict (or non-strong) code if you opted into that mode, and catching those errors defeats the purpose of using it. But it's not only true of mode switches... try { JSON.parse("{}"); } catch(e) { // onl…

Post by acjohnson55 » Thu, Mar 12, 2015, 11:25 AM UTC

tragic wrote: post #32

fapjacks wrote: post #27

Earlier quoted context omitted.

Which are some of the most insidious bugs possible in JS. I shudder every time I see the syntax in your post's parent. It's a red flag. Your solution is good. I also use a lot of typeof(bar.x) !== 'undefined' since it's very explicit.

Every time? I mean, very many times (for example) you're pulling in some JSON from a server app, which will have types properly enforced at the database and/or application level. There are still gotchas around defaulting to true, whether or not an empty string is a valid value and so on, but there are many cases where foo || bar is safe enough.