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

Show HN: ES7 Decorator library adds types checking, memoization, and more to JS

github.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS

#21

Post by braythwayt »

mako-taco wrote: post #11
jeswin wrote: post #7

Correct me if I'm wrong, but the necessity for decorators seem to have risen from the ES6 class syntax. If we were doing classes/functions the old imperative style, we could have simply wrapped the RHS in a standard function that does what the decorator does. Animal.prototype.speedup = typeCheckDecorator("number", "number", function(x) { this.speed += x; return this.speed; }); I get that the class syntax makes things…

Static analysis is one of the end goals of this project; the other is generating documentation. Decorators are definitely NOT needed for achieving the current functionality.

A beautiful and elegant thing about JavaScript is that decorators are not needed for the current functionality, as you say.

That being said, some people feel very strongly that languages are better tools when they are less elegant, when they are collections of specialized tools that communicate very specific intentions to readers.

Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS

#23

Post by braythwayt »

jeswin wrote: post #7

Correct me if I'm wrong, but the necessity for decorators seem to have risen from the ES6 class syntax. If we were doing classes/functions the old imperative style, we could have simply wrapped the RHS in a standard function that does what the decorator does. Animal.prototype.speedup = typeCheckDecorator("number", "number", function(x) { this.speed += x; return this.speed; }); I get that the class syntax makes things…

This kind of thing is particularly elegant in CoffeeScript:

    Object.assign Connection.prototype,
      hostname: memoize () -> @host.getRemoteName()

Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS

#24

Post by reipahb »

wslh wrote: post #18

It seems like dynamic programming languages end up implementing decorators. To specify types it would be better to specify them in the parameters instead of adding a few lines.

I don't think programming languages implement decorators in order to facilitate type checking. They implement decorators because they are a nice generic way to reuse code in many functions / classes.

Now, once you have support for decorators, they can obviously be reused for type checking, but the linked repository also contains a few more decorators such as a memoization decorator.

I think those that add type checking decorators do so because it is a convenient way to add a some common code to multiple functions. The alternative for those that add decorators is to manually add a set of type checks in the beginning of each function.

Of course, if the language supported type checking they would simply use that, but if not, this is a simple way to save some lines of code.

Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS

#26

Post by underwater »

untog wrote: post #20

Interesting - I wonder whether TypeScript could compile down to this when ES7 is accepted and live in browsers. As it is, I do prefer the syntax of TypeScript.

This does runtime checking. Flow and Typescript do static type checking. Which, as long as the systems are sound, means you don't need a runtime component.

Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS

#27

Post by jkrems »

untog wrote: post #20

Interesting - I wonder whether TypeScript could compile down to this when ES7 is accepted and live in browsers. As it is, I do prefer the syntax of TypeScript.

Afaik TypeScript is using https://www.npmjs.com/package/reflect-metadata to attach runtime type information, something angular asked them to do (there was no runtime information before). See also: https://github.com/Microsoft/TypeScript/issues/3148

Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS

#29

Post by TazeTSchnitzel »

jeswin wrote: post #7

Correct me if I'm wrong, but the necessity for decorators seem to have risen from the ES6 class syntax. If we were doing classes/functions the old imperative style, we could have simply wrapped the RHS in a standard function that does what the decorator does. Animal.prototype.speedup = typeCheckDecorator("number", "number", function(x) { this.speed += x; return this.speed; }); I get that the class syntax makes things…

They aren't necessary in Python, either.

But having syntactical support improves readability.

Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS

#30

Post by loganfsmyth »

jeswin wrote: post #7

Correct me if I'm wrong, but the necessity for decorators seem to have risen from the ES6 class syntax. If we were doing classes/functions the old imperative style, we could have simply wrapped the RHS in a standard function that does what the decorator does. Animal.prototype.speedup = typeCheckDecorator("number", "number", function(x) { this.speed += x; return this.speed; }); I get that the class syntax makes things…

The main other benefit of decorators is that they work on property descriptors, and are automatically passed property names and the target object, so you have a bit more info.

Having the descriptor means for instance that you can switch a value to use a getter function, and that enables a bunch of interesting functionality that you couldn't otherwise do.

One example that I like is automatically binding methods to the current instance on first property access.

Post reply on HN