4 ms·

This is dead on arrival: Some examples of strong mode changes we are aiming for are: accessing missing properties throws, arrays cannot have holes,

• masklinn 12y ago
  > Options objects require this as a feature. Object.assign(defaults, options) The defaults object has all the necessary properties, no missing property access is necessary.
  • eldude 12y ago
    I think this is part of the problem. Adopting "strong mode" will make lots of modern code obsolete. At least there are sane alternatives though, but it would also require setting empty properties on classes and undermine duck-typing. Yes, it's doable, but it fundamentally requires a non-dynamic approach to JavaScript programming, a highly dynamic language.
    • masklinn 12y ago
      Object.assign (or equivalent with libraires like jQuery or Underscore or what have you) is very much modern code. Hell, Object.assign is ES6.
      • eldude 12y ago
        You misunderstand. Object.assign is as available today as is `typeof foo.bar === 'undefined'` or `_.defaults(...)`. Yet I doubt even the majority of modern code always uses them consistently because `if (foo.bar)` or `foo.bar = foo.bar || 1234` is much simpler and much faster.
    • frio 12y ago
      > Adopting "strong mode" will make lots of modern code obsolete The same could have been said for strict mode.
      • eldude 12y ago
        Yes, but that's exactly my point; "strict mode" eliminated a lot of the consensus "bad parts". "strong mode" discourages modern utilized features. Not only are accessing undeclared properties and mutating classes not considered "bad" by the majority of the community, but in fact they're actively relied upon as a feature. It's almost as if Google didn't bother convincing anyone they were bad, because they wouldn't succeed, and instead jumped straight to ruling by fiat, which is precisely why in my opinion this is dead on arrival.
        • magicalist 12y ago
          > It's almost as if Google didn't bother convincing anyone they were bad That's what this proposal is. You can disagree and discuss alternatives, and that's great, because that's how standards get written.
          • eldude 12y ago
            > That's what this proposal is. Perhaps you're right, and I merely remain wholly unconvinced, though I acquiesced in the OP that perhaps it will be necessary. Optimizability dictating language features to this extent is the tail wagging the dog. I think this would undermine the ecosystem by creating a subset that is neither Java nor JavaScript, neither safe nor dynamic; a lowest common denominator of sorts that may do more harm than good in the competition with native.
            • marrs 12y ago
              Going slightly away from the topic, which I agree with you entirely on, btw... This is pure speculation on my part, but I wonder if a lot of the Google devs involved in JS in one way or the other just aren't that used to writing it. It's this quote that caught my attention Optimizability dictating language features to this extent is the tail wagging the dog. Apologies to Java devs if this is uncharacteristic of the community, but a lot of Java devs I know seem to put performance and vm internals ahead of expressiveness. AngularJS is another project that strikes me as being heavily Java inspired (although it's neither expressive nor performant), almost as if its authors are used to writing desktop applications in Java or C# and just wanted to port their experience to the browser. It's as though the authors of Gmail or Google Docs are not people developing these other things.
  • spicyj 12y ago
    (P.S. For the unfamiliar, that mutates `defaults` -- you might want Object.assign({}, defaults, options) instead if `defaults` is an object shared across invocations of your function.)
• BinaryIdiot 12y ago
  > Specifically, "accessing missing properties throws" will undermine how developers use the language. I couldn't agree more; there are many times I access a property that may or may not exist and I plan on using the undefined that comes with it not existing. Requiring it to exist is trying to turn JavaScript into a more strict language without all of the language features to do so very easily.
  • nawitus 12y ago
    I wonder if "SoundScript" will support optional properties. TypeScript also considers accessing missing properties a compile-time error, and I haven't noticed many problems with that as you can define some properties as optional.
    • jahewson 12y ago
      That would work at "compile" time, but how do we know whether or not a property is missing at runtime without accessing it? Or resorting to an expensive and minifier-hostile call such as hasOwnProperty? The TypeScript approach won't work here. Guaranteeing that optional properties have a default value would be one solution, another would be to use ES6 default parameters instead of options objects. But there has to be some sort of value to use at runtime if missing property access always throws.
  • i_s 12y ago
    It only throws if you access the property with the [] or . syntax, so I don't think this particular thing is a big problem.
    • EdwardDiego 12y ago
      What other syntax is there to access a property?
      • ianbicking 12y ago
        They only barely mention it, but I think they expect you do to `foo = 'foo' in obj ? obj.foo : undefined` instead of `foo = obj.foo`
• woah 12y ago
  "accessing missing properties throws" will just lead to a lot of use of try/catch, and the issues that entails. It's frankly doubtful whether it will speed things up at all, if there is any penalty to throwing try/catch everywhere.
  • the8472 12y ago
    or you can check first with .hasOwnProperty() or with the in operator
    • masswerk 12y ago
      if the client supports .hasOwnProperty() or the 'in' operator ... (it's just a few years that these were not common, and there are still clients around that don't support it)
      • Too 12y ago
        Got any examples of these browsers? IIRC i used hasOwnProperty as far back as IE6.
  • jahewson 12y ago
    That won't be a problem in SoundScript though, because any code which tries to access a property which might be missing is unsound, so it won't "compile" (or rather, it won't pass the type checker).
    • barrkel 12y ago
      In order for this to work, the type needs to be statically known, which in turn means type casts would be required when asserting a downcast. Javascript littered with casts is nothing I want to see. I don't know about you.
• jahewson 12y ago
  You can use ES6 default parameters to implement options objects, so instead of: function foo(x, options) { var y = options.y | 0; return x + y; } You can write: function foo(x, y = 0) { console.log(x + y); } Problem solved!
• xxgreg 12y ago
  > Options objects Options _Map_. There I fixed it.