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;
});
Decorators are definitely NOT needed for achieving the current functionality.
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.
> 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.
Object.assign Connection.prototype,
hostname: memoize () -> @host.getRemoteName()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.
But having syntactical support improves readability.
You can enable experimental es7 features: https://babeljs.io/docs/usage/experimental/
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.
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.
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.
https://github.com/wycats/javascript-decorators
Proxies are an entire different thing.
let addToFiveAndThree = addFive(3);
Should be:
let addToFiveAndThree = addToFive(3);
I belive.
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.
> 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.
you can't really do that (easily) with ad-hoc typecheck wrappers.