Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Strong Mode for JavaScript

docs.google.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: A Strong Mode for JavaScript

#21

Post by dustin1114 »

comex wrote: post #19
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…

That's funny; I think that's the only part of what the document proposes I like. -- Well, okay, that's not really true; there are a lot of bits that just make sense, either because they hurt performance for little benefit (holes in arrays) or they're just dumb (arguments.caller). But I don't like gratuitously locking things down in a way that makes highly dynamically-typed code harder to write, where it doesn't seem…

It's kind of funny. ES6 seems to be making JS more "Python", while "strong mode" makes it more like Java/C# (at least to me). I'm open to worthwhile changes; I'm just thinking about the tens of thousands of lines of JS I've written with various utilities and libraries, and how they will eventually fit into ES6...I'm not too sure about strong mode, though. I guess we'll see how it all pans out.

Re: A Strong Mode for JavaScript

#22

Post by dustin1114 »

reissbaker wrote: post #17
aeosynth wrote: post #13

Earlier quoted context omitted.

I think they're trying to push onto [Maps]. [Maps]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Yep, they're explicitly trying to do that. For what it's worth, you can still use "options hashes" in your argument APIs in strong mode using objects; you just write a library function something like: function options(options, defaults) { // the final args start off as a clone of the default args let args = Object.clone(defaults); // we then loop through the keys and copy in any overrides for(let key of Object.keys(a…

The Java (5+) Map interface can be typed using generics (which -- if JS eventually introduces static typing -- I hope is implemented).

  Map = new HashMap();
That declares a Map with a String key and Integer value. Is this what you're thinking of?

Re: A Strong Mode for JavaScript

#23

Post by reissbaker »

dustin1114 wrote: post #22
reissbaker wrote: post #17

Earlier quoted context omitted.

Yep, they're explicitly trying to do that. For what it's worth, you can still use "options hashes" in your argument APIs in strong mode using objects; you just write a library function something like: function options(options, defaults) { // the final args start off as a clone of the default args let args = Object.clone(defaults); // we then loop through the keys and copy in any overrides for(let key of Object.keys(a…

The Java (5+) Map interface can be typed using generics (which -- if JS eventually introduces static typing -- I hope is implemented). Map = new HashMap (); That declares a Map with a String key and Integer value. Is this what you're thinking of?

Not what I was thinking of, but I should've been more explicit. Using generics you can type the keys and values of Maps in any language with generic support that I'm familiar with: certainly C++ and Java can. But you can't make type assertions about certain values existing under certain keys: that's what structs/classes/etc are for. But, those constructs can't easily be generated at runtime, and are typed nominally: even just as a caller you have to explicitly say they inherit (or in Java, implement) a specific type. However, with TypeScript-like structural subtyping, you can do:

    interface BreadIngredientOptions {
      flourType?: String; // this is the syntax for optional strings
      sugarAmount?: String; // ditto: it's the ? that makes it optional
      // ...
    }

    function bakeBread(ingredientOverrides: BreadIngredientOptions) {
      // ...
    }

    // callers don't need to explicitly inherit or implement to be type checked
    // however, since all properties are optional, this is less interesting
    bakeBread({
      flourType: 'white'
    });
But you can do even better than that example shows. One common problem with maps-as-named-arguments is that you can't easily determine which arguments are required and which are optional. With typed optional properties and structural subtyping you can enforce that at compile time, as follows:

    interface MyArgumentInterface {
      requiredArg: number;
      optionalArg?: number;
    }

    function f(args: MyArgumentInterface) {
      // ...
    }

    // This works:
    f({
      requiredArg: 10,
      optionalArg: 5
    });

    // This also works:
    f({ requiredArg: 50 });

    // This statically throws at compile time:
    f({ optionalArg: 10 });
It's a combination of the simple object literal syntax from raw JS that makes it easy to create objects of arbitrary types, with structural subtyping. I'm not aware of any language with the same features (but would love to be corrected!).

Re: A Strong Mode for JavaScript

#24

Post by thalesmello »

jongleberry wrote: post #3
msoad wrote: post #2

> It is a SyntaxError to use the keyword 'var' What if I want a variable?!

use `let ` or `const `. there's no need to use `var` in ES6+, ever.

So, if I want get the sum of an array of numbers, the only option is to use recursion or a reduce function? Is there a way to accomplish this using a for loop while sticking to let keywords?

Re: A Strong Mode for JavaScript

#25

Post by Skalman »

thalesmello wrote: post #24
jongleberry wrote: post #3

Earlier quoted context omitted.

use `let ` or `const `. there's no need to use `var` in ES6+, ever.

So, if I want get the sum of an array of numbers, the only option is to use recursion or a reduce function? Is there a way to accomplish this using a for loop while sticking to let keywords?

Perhaps you didn't catch that basically the difference between let and var is that let is block-scoped, while var is function-scoped?

  let result = 0;
  for (let i = 0; i

Re: A Strong Mode for JavaScript

#26

Post by Sanddancer »

TazeTSchnitzel wrote: post #10
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…

Being able to do foo = bar.x || 3; rather than foo = bar.hasOwnProperty('x') ? bar.x : 3; is nice.

Personally, I would say

    foo = ('x' in bar) ? bar.x : 3;
instead. The problem with your code is that if the property bar.x exists, but is one of any number of values, like 0 or false, your code will still set foo to 3. Requiring properties to be explicitly created means that you're separating existence from value, which are two very different things in my book.

Re: A Strong Mode for JavaScript

#27

Post by fapjacks »

Sanddancer wrote: post #26
TazeTSchnitzel wrote: post #10

Earlier quoted context omitted.

Being able to do foo = bar.x || 3; rather than foo = bar.hasOwnProperty('x') ? bar.x : 3; is nice.

Personally, I would say foo = ('x' in bar) ? bar.x : 3; instead. The problem with your code is that if the property bar.x exists, but is one of any number of values, like 0 or false, your code will still set foo to 3. Requiring properties to be explicitly created means that you're separating existence from value, which are two very different things in my book.

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.

Re: A Strong Mode for JavaScript

#28

Post by leichtgewicht »

wwweston wrote: post #18
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…

It does break fundamental uses of the language. Throwing on missing properties is a near-hostile change for most current JS developers. The given justifications for doing this, though, seem to be all about performance rather than an attempt to evolve the language. If that's true, I think it's possible the proposal has a naming problem. Calling it "use strong" implies that this is about evolving the JS language so tha…

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

Re: A Strong Mode for JavaScript

#29

Post by leichtgewicht »

First: this document should be on github. How do I do a PR on a google doc?

My biggest problem with this proposal is that it will force a full-blown code-style on you. Many, perhaps most, of the features will be part of the common consent how to write good apps but I am sure lots of people have a problem with feature x or y. I wonder if a "selecting a subset" would be practicable.

Re: A Strong Mode for JavaScript

#30

Post by pygy_ »

leichtgewicht wrote: post #28
wwweston wrote: post #18

Earlier quoted context omitted.

It does break fundamental uses of the language. Throwing on missing properties is a near-hostile change for most current JS developers. The given justifications for doing this, though, seem to be all about performance rather than an attempt to evolve the language. If that's true, I think it's possible the proposal has a naming problem. Calling it "use strong" implies that this is about evolving the JS language so tha…

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 reply on HN