On Sun, Nov 29, 2009 at 8:53 AM, David Chelimsky <dchelim...@gmail.com> wrote: > On Sun, Nov 29, 2009 at 12:33 AM, rogerdpack <rogerpack2...@gmail.com> > wrote: >> >> It is somewhat surprising to me, as a newbie, to have to assert >> a.should be_a(Hash) >> >> That extra space in there feels awkward. >> >> Suggestion: >> >> allow for constructs like >> a.should.be_a(Hash) >> >> Thoughts? > > You're about 4 years late to the party. We were playing around with a > variety of options back in 2005 and went with the current syntax because it > gave us the most flexibility and the highest level of decoupling, making it > easier for others to create their own matcher libraries. While it would be > technically feasible to support should.matcher, doing so now would cause > more confusion for more people than be helpful, IMO.
I might be wrong, but IIRC RSpec used to use the .matcher form in the early days. And when it did there was a lot more in the way of methods added to Kernel, and that's one of the reasons I avoided RSpec back then, way too much Heisenberg effect. With the current design, there's very little added to all Ruby objects, just Kernel#should and Kernel#should_not and that's it. I guess that's the decoupling you're talking about. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
