3 ms·
I think the argument is that solutions such as Timecop are a hack for stubbing dependencies that are pulled out of global scope.
by chrismsnz 14y ago
I think the argument is that solutions such as Timecop are a hack for stubbing dependencies that are pulled out of global scope.
- Xylakant 14y agoAt some point you will need to test the unit that create the time object. With DI you could swap out the implementation of time that gets created and use some implementation that returns a constant time. But that still pulls the information about the implementation to use from some global scope: The DI library needs to know which implementation to use, and that information will come from some global scope - a configuration of some kind, thus making that argument a moot point. In ruby you can modify the classes at runtime to mock such functionality. You could argue that modifying the time implementation is some form of DI - you're changing the implementation at runtime.
- mercurial 14y agoDI is still relevant for dynamic languages, for two reasons: - it lets you put your dependencies all at the same place - it lets you define clearly what the dependencies of a piece of code are, without having to look at internals which may change tomorrow without warning One thing I find aggravating with dynamic languages is that metaprogramming is a crutch people tend to rely on because they can't be bothered to write clean APIs. In my experience, it's particularly prevalent in Ruby. Of course, the lack of dynamism can be a problem in statically typed languages, giving Spring's or Hibernate's stacktraces of hell with piles of proxy objects.
- mpweiher 14y agoVery succinctly put. Newspeak solves this by eliminating the global scope and eliminating "import". Every module is parametrized with everything it needs.
- h2s 14y agoTimecop.freeze(Date.today + 30) do assert joe.mortgage_due? end vs assert joe.mortgage_due?(Date.today + 30)