On Wed, Oct 1, 2008 at 11:29 AM, Michael Latta <[EMAIL PROTECTED]> wrote:
> The point is to never assume the structure of another object, but to let it > decide that. So you never get A.B.C you always use a method on A to do the > work. You get a lot more methods on A but the structure underneath can > change without a ripple effect. > Sounds like future-proofing to me. In the case of libraries, that can be a good thing. For application code, it flies in the face of YAGNI. Using plugins that do this too simply removes some of the value. If they > always map the underlying structure you have not gained much. > Yes, it was the "auto-demetering" that I was mainly responding to. The whole convention over configuration means that the underlying structure > tends to be exposed more than good software engineering practice would > advise, but it works because most of the time the cost to fix a change is > actually lower in Ruby than the cost of preventing the change. > "Embrace change" - Kent Beck. The whole white book is predicated on what you just pointed out about Rails. But here I go again, off the RSpec track... ///ark
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
