In php I could have type hints to recommend the interface I wanted to be injected into my method or ask for certain dependencies.
Sure, I can do it myself but that seems painful compared to what php gave me out of the box.
You don't have to be a jerk about it, but a little structure can go a long way.
For some reason many of the rails community read a post against DI frameworks, and decided it was ok not to do DI. Because if you duck type it a frame work is a philosophy.
The results speak for themselves. Clearly a level seven ruby developer wrote the ruby CAS rails plugin, which had no tests, is a super singleton, and does whatever the hell it wants with your controller. Define two alternative logout uris? Not on its watch!
I admit the design is from 2006 or earlier when not so many people were enlightened, but I am still stuck with it.
On a library designed by people who develop for computer literate universities.
Cut the cord people, stop doing magic and just make a simple utility class or three.
There seems to be a jerk who said not to program defensively.
Thanks, that guy. The result is execution of an app continues well pat the danger input point because of a general principle.
Think about it for a minute, with the observer pattern.
Some input happens, events trigger. Now there are fifteen event listeners and they all freak out half way through executing because off some failed expectation.
A simple exception to check the input often points directly at the problem, but in ruby land you just let execution continue in general.
Most dissuading about this, those that discuss it on the Web tend to agree that you should check input and bug out.
The point is not to fail silently. But rails land doesn't care. It is going to make poor code poorly while screaming look at my ruby FU.
If rails developers, by and large left the power offered by ruby well enough alone and coded for other humans, life would be far, far better.
KISS > DRY