[rspec-users] surprising...

Rick DeNatale 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>
> 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

More information about the rspec-users mailing list