Interface Enforcement

I wonder if one needs InterfaceEnforcement at compile time to build large systems? Apparently not. --MartinPool

The main purpose of type-checking and InterfaceEnforcement at compile time is to ensure that the code references objects of the correct type.

If you have a long compile-link cycle, this information can be useful, because it's so long before you can actually test. However, the compile-time checking does not find all defects, so that you need actual UnitTests and FunctionalTests to assure yourself that the program actually works.

A case can be made that the slower and more cumbersome your program's build process is, the more valuable InterfaceEnforcement at compile time would be. And conversely. --RonJeffries

OK, that certainly fits with my experience in PythonLanguage.

In a well-designed system written in C, StaticChecking? catches (say) 30% of errors -- not many SemanticConstraints? can be enforced at compile time. But I find I make probably three times fewer errors in Python, and the ones that do get in are easier to catch in tests and easier to debug. So overall StaticChecking? is not much of a loss.

JavaLanguage has better static checks than C, but at the same time a more cumbersome compile and run process. So it is an advance, but not as much as it might have been. -- MartinPool

Question: Could someone please explain how InterfaceEnforcement is different from TypeChecking? Thanks.

AnswerMe

CategoryInterface