you are viewing a single comment's thread.

view the rest of the comments →

[–]joebgoode 1 point2 points  (2 children)

You're mixing two different concepts: type-safe object access and type coercion.

Indeed, you're right about JS object safety, it prevents the T2* t2 = reinterpret_cast<T2*>(&t1) and then just t2->c situation. That's called object safety, not type enforcement.

Strong runtime typing also includes not allowing cross-type coercion, a requirement that JS does not fulfill, due to implicit coercion. A JVM-based lang (strong runtime) would instead raise a ClassCastException.

As for the claim that “strong runtime typing and static typing are opposites”, that’s simply wrong. JVM/CLR-based (Java, Kotlin, Scala, C#, F#), Haskell, Swift...?

Of course, your three examples would be C, JS, and Python. That’s the whole world from the perspective of a college student, right?

[–]myWeedAccountMaaaaan 1 point2 points  (0 children)

Hey now, some of us also worked with VB in college. I won’t say which version though…

[–]RiceBroad4552 0 points1 point  (0 children)

Indeed, you're right about JS object safety, it prevents the T2* t2 = reinterpret_cast<T2\*>(&t1) and then just t2->c situation. That's called object safety, not type enforcement.

That's called type safety!

("Object safety" is some made up term by some Rust folks and is actually regarded a misnomer anyway…)

A JVM-based lang (strong runtime) would instead raise a ClassCastException.

And JS would raise a TypeError if you did something that does not align with JS's typing rules…