rick.denatale at gmail.com
Mon Nov 30 08:29:38 EST 2009
On Sun, Nov 29, 2009 at 8:53 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Sun, Nov 29, 2009 at 12:33 AM, rogerdpack <rogerpack2005 at gmail.com>
>> 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.
>> allow for constructs like
> 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
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.
More information about the rspec-users