Doesn't the ability to cast defeat the purpose of typed variables?

Question

So, I'm working under the assumption that we have typed languages because we make a lot of mistakes... so typing is one way to have the compiler do a lot of checks for us and help us out a bit (please let me know if it is my assumptions that's incorrect).

However, if we introduce casting to a typed language, don't we re-introduce most the problems we had when were not able to type variables?

I'm also aware that my assumption isn't the only reason why we type variables. Please share some of the other reasons why we have typed languages.

Answer 1

so typing is one way to have the compiler do a lot of checks for us and help us out a bit

Yes.

However, if we introduce casting to a typed language, don't we re-introduce most the problems we had when were not able to type variables?

Yes.

You should avoid it to the extent possible, but sometimes you still need to do dirty work.

Of course, there are plenty of languages that do not enforce strict typing, and plenty of people who like them and get useful work done with them.

Answer 2

Yes, strong types allow the compiler to do lots of checks for you.

No, allowing casting doesn't stop that being useful. The point is that the rare occasions when you need to do a cast, it is explicit. The programmer has to make a decision to make the cast and can be careful about it. Casting is a useful tool, like many powerful tools it should be used with care.

Answer 3

The bottom line is that strong typing lets the compiler check things for you and casting lets you override the strong typing when necessary.

Answer 4

When you cast, you explicitly ask the compiler to relax its otherwise strong typing. This allows you to have compile-time checking in 99% of the cases, yet still mix types when absolutely necessary.

Regardless, it is possible for the compiler to find "bad" casts at compile time - ones that have no chance of ever succeeding.

So saying that enabling casting negates the benefits of strong typing is a mistake. This can be said of overusing casting however.

Answer 5

I'm going to say "mostly no."

If you have to do explicit casts, you're still avoiding most of the problems introduced with dynamic typing. Your methods still need to exist on the new class. The objects still have to have some hierarchical relationship with each other.

There's a world of difference between being able to cast an XmlTextReader to a TextReader and being able to decide at run-time that reader has a member that's called "read" and might be a boolean or might be a method.

Answer 6

Typing also allows tools like Visual Studios Intellisense to work, which are a great help to productivity.

But beyond that, Mike B is right. Sometimes you just need to do something dirty, like casting interfaces up to classes, or longs to int.

Answer 7

At least in Java, not really. You can only cast to a child of the class you expect. So if your class returns a RuntimeException, you can't cast it to a String, and you don't need to cast it to access it as an Exception (it's parent).

You only have to cast it to say that you know this is actually a child/implementation of RuntimeException and you need to access something the child knows about that RuntimeException does not know.

That said, too much casting is a bad OO smell. You should access a child's unique code almost exclusively through the parent's exposed methods--if you find yourself casting a lot, perhaps you forgot this rule.

Answer 8

However, if we introduce casting to a typed language, don't we re-introduce most the problems we had when were not able to type variables?

I didn't see a language specified but it should be pointed out that there are different degree's with respect to casting.

C++ for instance has a dynamic_cast which will return NULL if an object can't be cast to another via its inheritence relation ship.

A const_cast will cast away the constness of an object. This could be useful for passing a const object to a method that isn't declared const but you know won't change the object.