> Why do you even assume classes are involved? Because classes are almost ubiquitous in modern commercial programming? > If you want to do a ChildClassA opera

> Why do you even assume classes are involved? Because classes are almost ubiquitous in modern commercial programming? > If you want to do a ChildClassA operation if that's that, you check whether that's what you have, then do the operation. Both are enforced by the compiler (though how safe the check is varies). Go to GitHub and search for "GetType language:csharp" or "getClass language:java" and see millions of hits for runtime checking in “statically typed languages". And who knows how many ad hoc runtime checks there are in C++ and other languages without a default reflection framework. > If you have a dynamically typed language, you might think you have a ParentClass but you actually have a completely unrelated ToyotaSupra. So is a dynamic language that supports type annotations in comments (eg JavaScript + JSDoc) actually a statically typed language? > Extremely. Because you know what the potential is, and you have to check for it exhaustively. It’s still going to be a mess that should be refactored. > So complete nonsense to make you feel good? You can do runtime type checks in “statically typed” languages. You can use type inference in “dynamic” languages. That is just facts.