Perhaps they should have done this up front, you know as part of the engineering, hence my point. Stopping and thinking for a bit usually covers these problems. I've read a huge chunk of the rails framework source code and it certainly used to be a pretty amateur piece of kit.

The argument is definitely not preposterous. Are you saying guarding against bad inputs and enforcing type is bad? A language which uses no type inference has less assumptions therefore is likely to be less error prone. I've proven this hundreds of times over the last 30 years of writing code in things from communications electronics to financial quotation platforms.

>Perhaps they should have done this up front, you know as part of the engineering, hence my point.

And you know what, I have a feeling they did have multiple people looking over the code, and it's been vigorously refactored over the years. Rails 3 is a somewhat different beast from Rails 2.

Careful auditing reduces bugs but does not eliminate them. Crowing about "proper engineering" is very nice but is somewhat farcical given the state of the art in the industry.

>Are you saying guarding against bad inputs and enforcing type is bad?

No. Of course you guard against bad inputs.

But that's wholly separate from enforcing the type of the objects. And it's not like people are eval()ing stuff willy-nilly.

Enforcing the type is important.

For example float vs decimal types in finance. You really want your bank running on floats when doing interest calculations?

"Actually, this bug was discovered precisely because people began to perform a more in depth analysis."

From Wikipedia: Ruby on Rails - Initial release July 2004

Eight-and-a-half years later, in depth analysis has come about to find this? (The exploit is present through 3.2, meaning it's been around all that time).