6 ms·
Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
- deleted 11y ago[deleted]
- mako-taco 11y agoThanks. My phone doesn't know what programming is :(
- deleted 11y ago[deleted]
- krat0sprakhar 11y agoCan someone recommend a simple and easy-to-approach tutorial into ES7 decorators? I have used decorators successfully in my previous Python projects, and I'm eager to start using them in JS. Unfortunately, I haven't yet come across a good guide till now.
- cnp 11y agoCheck out the spec: https://github.com/wycats/javascript-decorators https://github.com/wycats/javascript-decorators
- piran 11y agoTake a look at http://babeljs.io http://babeljs.io You can enable experimental es7 features: https://babeljs.io/docs/usage/experimental/ https://babeljs.io/docs/usage/experimental/
- thomasfoster96 11y agoIs something similar to this possible with ES6 proxies? It'd be nice to use a lot of these features outside classes, but since proxies are far harder to polyfill (indeed, I don't think anyone's some it yet) I've only seen then done with decorators within classes.
- piran 11y agoNo these aren't the same as proxies. ES7 has class decorators that can only be used on class methods.
- thomasfoster96 11y agoI know they're not the same, but I'd love to be able to use some of the thins I can use with decorators, but on plain objects.
- eltaco 11y agoYou can also use them on class declarations themselves and object literals - https://github.com/wycats/javascript-decorators#object-literal-method-declaration https://github.com/wycats/javascript-decorators#object-liter...
- mako-taco 11y agoes7 decorators can also be used on vanilla objects, not just classes.
- thomasfoster96 11y agoReally? Any tutorials/posts/examples of using them on plain objects anywhere?
- mako-taco 11y agoYeah, check some of the examples in the readme
- aikah 11y agoyou dont need proxies, here is how decorators work and how you can implement them yourself, without the syntactic sugar obviously https://github.com/wycats/javascript-decorators https://github.com/wycats/javascript-decorators Proxies are an entire different thing.
- jeswin 11y agoCorrect 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 easier for people coming from other languages. And maybe makes static analysis easier. But still not sure if it was really needed.
- mako-taco 11y agoStatic 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.
- braythwayt 11y agoA 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.
- deleted 11y ago[deleted]
- braythwayt 11y agoThis kind of thing is particularly elegant in CoffeeScript: Object.assign Connection.prototype, hostname: memoize () -> @host.getRemoteName()
- TazeTSchnitzel 11y agoThey aren't necessary in Python, either. But having syntactical support improves readability.
- loganfsmyth 11y agoThe 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.
- wslh 11y agoIt 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.
- reipahb 11y agoI 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.
- braythwayt 11y ago> 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. Well, in JavaScript, it’s particularly easy to write decorators as plain old JavaScript functions. Lots of libraries provide implementations that provide memoization or parameter checking on both functions and methods. So in the short term, decorators serve only to work around the fact that ES-6 classes actually make this more difficult than ES-5 idioms. But in the long term, a decorator can be extended to deal with static analysis, while functions provid eno such capability, so we’d be back to having “magic comments,” or inventing a new kind of pragma. So, I’d say that the motivation is to lay the groundwork for things involving static analysis or manipulation of programs. Like type checking, or even manipulation of the AST.
- untog 11y agoInteresting - 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.
- deleted 11y ago[deleted]
- underwater 11y agoThis 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.
- gsnedders 11y agoTypeScript isn't sound, and does rely on runtime checking for a small amount of stuff. I don't know about Flow.
- jkrems 11y agoAfaik TypeScript is using https://www.npmjs.com/package/reflect-metadata 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 https://github.com/Microsoft/TypeScript/issues/3148
- salimmadjd 11y agoIs there a typo on the Currying example? let addToFiveAndThree = addFive(3); Should be: let addToFiveAndThree = addToFive(3); I belive.
- mako-taco 11y agoFixed, thanks
- skrebbel 11y agoThis is exactly what I was looking for. Thanks! I can now retire most of my ugly home cooked precondition checking.
- aaron-lebo 11y agoES/JS continues to get more and more pythonic. Unless you really need a certain library (which is a really good reason), it is getting harder to pick Python over Node for new projects.
- z3t4 11y agoI used to argue for type decorations, like in most C like languages, but then changed my mind. When programming in a high level language like JavaScript, you should not think about types. Thinking about types will only limit your creativity and problem solving. Instead, you should focus on the logic abstraction. Also you shouldn't lock yourself into classifications. Instead, just check the input and throw an error if it doesn't fit.
- mschulze 11y ago>Also you shouldn't lock yourself into classifications. Instead, just check the input and throw an error if it doesn't fit. I really don't see the gain here - instead of delegating the typechecks to a tool, the compiler you clutter your code with them. You still have to think about the types, functions/methods (public ones) start with at one, two or more ifs and you even have a hit on runtime perfomance.
- z3t4 11y agoBy helping out the compiler you can get better performance. But I like to think that current JavaScript engines or future ones are quite smart and can optimize beyond that. Lets say you are writing software for a cargo company ... The code has well defined classes. The company now wants to expend by including buss goods. But in the code, the terminals and containers will only accept trucks ... It would be better if the terminal code checked if the good fitted etc. Thinking about Buss vs Truck is much better then thinking about Array vs Object, but you shouldn't let classifications limit the solutions either.