3 ms·

I just use asserts for this. If code is sensitive to a type I assert it as the top of the function. No analysis needed.

• arjie 12y ago
  But in a rare code path, that may not to be triggered. And if you write a unit test solely to catch the fact that the type is necessary, then obviously using a static type would be better because you get the benefit without the extra code for the test. Having optional typing does save you the trouble of overly complicated types for things where you aren't particularly concerned.
  • Touche 12y ago
    I don't understand what you mean by "But in a rare code path, that may not to be triggered." Can you explain? I wasn't suggesting using tests; I was suggesting using asserts. Directly in the function that is type sensitive. If that function is ever called with an incorrect type it will throw an exception. I get the benefit of optional type checking without a compile step in development like with Flow.
    • arjie 12y ago
      Well, I assumed you'd want to spot that error before it happens rather than when it does. The exception being thrown by the assert (at run-time) means that the user sees the failure. That's sub-optimal, right? So you'd ensure that there is testing of all code that calls this code in order to trigger the exception ahead of time if that occurs. Or am I misunderstanding? It just seems that the assert applies the constraint too late in the process. It doesn't ensure you have the right type once you've deployed. Instead it ensures failure on wrong type, which is something different.
      • Touche 12y ago
        I'm not sure if what you are describing is that realistic. A function that is used in some weird incorrect way that it won't get caught in development, QA or unit testing? Perhaps that can happen, but it's not been my experience. I use assertions liberally; they are especially helpful when refactoring and trying to figure out all of the dependent code that needs to be updated. Sure it's less certain than what you get from a compiler; that's the tradeoff for not having to compile in development. Since most JavaScript code is not type-sensitive it's only important in code that you are more than likely going to be testing heavily anyways.
        • arjie 12y ago
          The point is that you substitute the extra testing and QA with types. The assertion doesn't guarantee type correctness, so you test that function and downstream functions. That's extra code burden. Instead, you could have type checking.
          • Touche 12y ago
            I disagree, tests and QA happens regardless. Adding a compile step to development is a big downside to the type approach.