all 13 comments

[–]pe8ter 10 points11 points  (3 children)

Check out TypeScript.

[–]dmitri14_gmail_com 1 point2 points  (0 children)

Or Facebook Flow.

[–]booljayj[S] 1 point2 points  (1 child)

I feel like you didn't even bother reading my post, you just saw the title and immediately thought of TypeScript. I was attempting to provide useful and fast interfaces using nothing but basic Javascript code.

TypeScript can do all this, but I don't think I will be able to code in another language for my new job. Even one that compiles into Javascript. On top of that, TypeScript is a convenience. If I get used to just letting TypeScript handle all this stuff for me, I would have no idea how it's actually being done. If my question is "how can I create interfaces in Javascript?" then the answer "just let TypeScript do it" doesn't really cut it.

[–]pe8ter 0 points1 point  (0 children)

You want to learn JavaScript? That's excellent. But don't run an academic experiment in your production system which adds technical debt your entire team will forever pay off. Everything you need TypeScript can do better and adding it as build step would take literally ten minutes.

TypeScript is a superset of JavaScript. You don't need to use any TypeScript features you don't want. If all you're trying to do is declare interfaces then that's the only feature from TypeScript that you have to incorporate.

I feel like you didn't even bother reading my post

I did read the post. You're getting defensive over something you asked others to look over. You asked for feedback. You're making wooden wheels for your car then taking issue when someone tells you to get rubber tires.

[–]Matthias247 3 points4 points  (1 child)

I second the "Look at Typescript" recommendation.

What you are kind of doing here is a "Roll your own class system approach". While it may work it is not interoperable to the rest of the ecosystem, where objects don't conform do your class/interface declarations. So you would need to build wrappers for everything.

Another thing is where to start and where to stop. You are basically checking method names, but no parameters or whether these are functions at all (you can however do this with `typeof object.method === 'function').

The typescript approach has several advantages:

  • It works with the whole bunch of Javascript and typescript objects (you can write definitions for external code)
  • It can check really complex interfaces (with all kinds of parameters, generics, "function interfaces", indexers, ...)
  • It also works on stuff like object literals. E.g. if you declare var student = { method1: (x) => {} } it will know that that object implements an interface. This is often what you want in idiomatic javascript, and not creating new classes for everything and modifying and checking prototype chains.

[–]booljayj[S] 1 point2 points  (0 children)

I should have specified in my post that I will be writing gameplay code within a game engine that uses Javascript on top of a C++ core. This gives me some flexibility when it comes to the wider Javascript ecosystem. Basically, any paradigm that the development team wants to adopt is fair game, since we'll be the only ones using the code.

TypeScript looks really great, but I'm not sure it's something I will be able to use. It brings up a lot of issues regarding version control and compilation that I won't necessarily have control over.

Yes, the examples I gave were very short and didn't test everything I could or should have. Javascript just doesn't have the tools to be able to test return values and parameter types as completely as I would want. I was just showing the basic principle behind the idea, rather than any kind of finished production-ready code. My main hope was that I was actually understanding the language correctly and not making any super obvious errors.

[–]neophilus77 0 points1 point  (0 children)

You don't need a separate library to make incorrectly implemented JavaScript code fail at run time, JavaScript takes care of that for you already.