

Show HN: ES7 Decorator library adds types checking, memoization, and more to JS - mako-taco
https://github.com/mako-taco/DecorateThis

======
jeswin
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 easier for people coming from other
languages. And maybe makes static analysis easier. But still not sure if it
was really needed.

~~~
mako-taco
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.

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

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

~~~
piran
Take 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/)

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

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

~~~
gsnedders
TypeScript isn't sound, and does rely on runtime checking for a small amount
of stuff. I don't know about Flow.

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

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

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

~~~
piran
No these aren't the same as proxies. ES7 has class decorators that can only be
used on class methods.

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

~~~
eltaco
You can also use them on class declarations themselves and object literals -
[https://github.com/wycats/javascript-decorators#object-
liter...](https://github.com/wycats/javascript-decorators#object-literal-
method-declaration)

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

------
skrebbel
This is exactly what I was looking for. Thanks! I can now retire most of my
ugly home cooked precondition checking.

------
salimmadjd
Is there a typo on the Currying example?

let addToFiveAndThree = addFive(3);

Should be:

let addToFiveAndThree = addToFive(3);

I belive.

~~~
mako-taco
Fixed, thanks

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

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

~~~
braythwayt

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

