Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
github.comCorrect 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;
});
IMHO the biggest advantage of having class syntax is there's now one "blessed" way to do classical inheritance in JavaScript, whereas until now every JavaScript library implement their own slightly different (potentially incompatible) system.
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.
> And maybe makes static analysis easier.
> But still not sure if it was really needed.
That depends on your definition of "needed" of course. Do we need any abstractions? Why not just write assembly, nay, machine code?
Static analysis enables a lot of tooling (accurate auto-completion, compile-time type checking, null-analysis, ) and can also make life easier for the JIT compilers[1].
On the one end of the spectrum it's not needed because as long as a language is turing-complete it can do anything any other turing-complete language can do. On the other end it is needed to make your life easier and be more productive by offloading work from your brain to the CPU.
I'd argue this abstraction isn't any higher-level than the function equivalent above. More readable, maybe.
explicit annotations following a specific syntax can be analyzed by a checker.
you can't really do that (easily) with ad-hoc typecheck wrappers.
This kind of thing is particularly elegant in CoffeeScript:
Object.assign Connection.prototype, hostname: memoize () -> @host.getRemoteName()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.
They aren't necessary in Python, either.
But having syntactical support improves readability.
One disadvantage of adding syntactic sugars for things you can already do, is that the language gets more difficult to understand. This in turn introduce more bugs and hurts the productivity.
Can 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.
Take a look at http://babeljs.io
You can enable experimental es7 features: https://babeljs.io/docs/usage/experimental/
Check out the spec: https://github.com/wycats/javascript-decorators
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
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.
TypeScript isn't sound, and does rely on runtime checking for a small amount of stuff. I don't know about Flow.
I 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.
>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.
By 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.
Is 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.
I once implemented type checking in ES5 as a proof-of-concept: https://github.com/panuhorsmalahti/typed-javascript
you 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
Proxies are an entire different thing.
No these aren't the same as proxies. ES7 has class decorators that can only be used on class methods.
I 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.
You can also use them on class declarations themselves and object literals - https://github.com/wycats/javascript-decorators#object-liter...
es7 decorators can also be used on vanilla objects, not just classes.
Really? Any tutorials/posts/examples of using them on plain objects anywhere?
Yeah, check some of the examples in the readme
ES/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.
This is exactly what I was looking for. Thanks! I can now retire most of my ugly home cooked precondition checking.
Is there a typo on the Currying example?
let addToFiveAndThree = addFive(3);
Should be:
let addToFiveAndThree = addToFive(3);
I belive.
Fixed, thanks
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.
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.> 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.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.