Hacker News Reader

> 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.

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.

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.

It only throws if you access the property with the [] or . syntax, so I don't think this particular thing is a big problem.

What other syntax is there to access a property?

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`

I really doubt it, as that's an unsound bypassing of the type system. Missing properties are slow in JavaScript, because the in-memory representation of the class has to be modified when new properties are added. Given that strong mode is about performance, it would make far more sense to just prohibit missing properties and encourage use of other ES6 language mechanisms such default parameters instead.

You check if is there before you access it with . or [].

Oh right. I love those null/undefined checking chains, it really puts the Java in JavaScript.

> 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.

(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.)

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.

Object.assign (or equivalent with libraires like jQuery or Underscore or what have you) is very much modern code. Hell, Object.assign is ES6.

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.

> Adopting "strong mode" will make lots of modern code obsolete

The same could have been said for strict mode.

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.

> 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.

That's a little too, um, "magical" a version of how standards get made.

In truth it's a pay-to-play sausage-making fest, with incumbents privileged against newcomers -- but at least with the Web, some 10M growing to 20M developers are the ultimate sued-to-woo power.

I'm not yet worried about Google cramming this down other browser vendors' throats. MS and Apple will only come on board when it's in a state where Mozilla is on board too, I predict. This may not happen, so don't count on anything. Do use and report usability and other bugs.

> 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.

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.

"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.

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).

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.

or you can check first with .hasOwnProperty() or with the in operator

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)

Got any examples of these browsers? IIRC i used hasOwnProperty as far back as IE6.

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!

> Options objects

Options _Map_. There I fixed it.