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 <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. 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> Much thanks. > -r > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20091129/6bad3c86/attachment-0001.html>
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
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
> 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
> 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