undefined | Better HN

0 pointssomehnguy2y ago0 comments

This is kind of a ridiculous thing to worry or think about. I’m seeing a lot of type inference in modern Java, and it’s the default way of writing Kotlin.

0 comments

3 comments · 1 top-level

breadwinner2y ago· 2 in thread

It is dangerous to call a method on an object whose type is not being checked by the compiler. Whether that's a ridiculous thing to worry about depends on how important your program is. If you work for NASA and your code will run inside the Mars rover, it is not ridiculous to worry about such things, but if you're writing some code that will be used once and thrown away then yeah, it might be ridiculous.

somehnguyOP2y ago

It is being checked by the compiler though. For your example to work both would need to extend a common object (unless the only thing you ever do to that object is call fire(), which is nonsensical) or you would get a compile time error right off the bat.

It's a ridiculous thing to worry about in either of your cases. That incredibly specific situation simply isn't ever going to happen in practice because so many other conditions need to be met for the compiler to let you proceed.

breadwinner2y ago

> For your example to work both would need to extend a common object

Not necessarily at all.

> unless the only thing you ever do to that object is call fire(), which is nonsensical

In this example, when the object is returned by a particular method, only fire() is being called, but other ways of obtaining the object can have more methods being called.

> It's a ridiculous thing to worry about in either of your cases.

Not at all... if your program is running inside a NASA rover, or if your program is running inside a robotic surgery machine you have to worry about safety and you want to maximize compile-time checks.

j / k navigate · click thread line to collapse