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?
Much thanks.
-r
On Sun, Nov 29, 2009 at 12:33 AM, rogerdpack
[email protected]wrote:
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.
If you’re really excited about that syntax (with the dots), there are
other
frameworks (test/spec and expectations to name two) that use it or
something
similar, so you might want to give those a peek as well.
Good luck!
Cheers,
David
On Nov 29, 2009, at 6:33 am, rogerdpack wrote:
It is somewhat surprising to me, as a newbie, to have to assert
a.should be_a(Hash)
Hi Roger
Once you see the matcher (ie be_a) as something that returns a matcher
object, it makes a lot more sense. My brain is now wired to give much
more weight to the thing on the right.
You might find it instructive/enlightening/life-changing (possibly) to
have a go at writing some custom matchers. From the RSpec docs[1]:
bob.current_zone.should eql(Zone.new(“4”))
becomes →
bob.should be_in_zone(“4”)
which is implemented with →
Spec::Matchers.define :be_in_zone do |zone|
match do |player|
player.in_zone?(zone)
end
end
Although I’ve just realised that RSpec’s dynamic be_* matcher actually
gives you that for free…
HTH
Ashley
[1] http://rspec.rubyforge.org/rspec/1.2.9/classes/Spec/Matchers.html
–
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
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.
Thanks for the feedback.
-r
On Sun, Nov 29, 2009 at 8:53 AM, David C. [email protected]
wrote:
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
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 guess the confusion comes from being able to do
a.should == ‘b’
a.should.== ‘b’
but not anything like
a.should.equal(‘b’)
== appears to be special cased? But I’m sure I’ll get used to it.
Thanks for the replies.
-r