This is exactly what I was looking for. Thanks! I can now retire most of my ugly home cooked precondition checking.
Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
31–40 of 43 posts
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#32It 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 checki…
> 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.
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#33Correct 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…
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.
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#34Correct 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…
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.
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#35ES/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.
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#36Correct 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…
> 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.
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#37Correct 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…
> 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…
I'd argue this abstraction isn't any higher-level than the function equivalent above. More readable, maybe.
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#38Earlier quoted context omitted.
> 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…
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.
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#39I 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.
Re: Show HN: ES7 Decorator library adds types checking, memoization, and more to JS
#40I 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…
>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.