All, If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 you''ll see that Chad (the submitter) found the source of the bug. Unfortunately, the source of *this* bug is the *solution* to a *previous bug* in which Rails was replacing RSpec''s method missing with its own. When we settled on underscores, my one reservation was that we''d keep running into this particular problem - RSpec''s method_missing conflicting with others. I have a proposition that preserves the underscore syntax, makes some examples even more clear, and eliminates this problem once and for all. 1. Eliminate reliance on method missing to handle expectations by adding all of the documented should_x_y_z methods directly to Object. These would all delegate off to Spec::Expectations::Should, ::Not, ::Have, etc, so the design wouldn''t change much and Object itself, though bloated w/ methods, would not be bloated w/ implementation. This would also give us a single expectations module that we add to Object, providing several benefits including: # more clarity in the API # a place to put meaningful rdoc # a potential formal plugin point 2. Change should_be to ONLY handle arbitrary predicates (not serve as an alias for should_equal): subject.should_be :empty => passes if subject.empty? subject.should_be :instance_of, SomeClass => passes if subject.instance_of? SomeClass etc... In my opinion (feel free to disagree), this actually makes these examples more readable. Consider these two: @bdd_framework.should_be_adopted_quickly #current @bdd_framework.should_be :adopted_quickly #proposed In my view, these read equally well from a language perspective AND they make it easier for a developer to mentally separate the expectation (should_be) from the expected value (adopted_quickly?). This WOULD require changes to existing specs. I think for those of you who don''t wrap expectation args in parens that a trivial script would handle this for you. If you do use parens, the script might be more complex. Perhaps if we *do* choose this direction, one of you would like to contribute such a script. I fully recognize that this would cause some pain, but it is my feeling that not addressing this leaves us in a crippled position in which we commit to being sidetracked by this issue constantly returning instead of focusing on enhancing the API. I also think that this is a better option than any of the following that also crossed my mind: * revert to dots * figure out a sexy way to intercept all attempts to rewrite method missing and re-inject RSpec''s method missing in its place (perhaps this does sound sexy, but I doth believe that there is a venereal disease hiding in its midst) * leave things as they are and continue to add ugly hacks like NilClass.handle_underscores_for_rspec! (that''s MY ugly hack so I get so call it that) * hang myself from the nearest bridge Of course, if you have any solutions to propose, I''m all eyes. Thoughts? Thanks, David
On 11/19/06, David Chelimsky <dchelimsky at gmail.com> wrote:> All, > > If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > you''ll see that Chad (the submitter) found the source of the bug. > Unfortunately, the source of *this* bug is the *solution* to a > *previous bug* in which Rails was replacing RSpec''s method missing > with its own. > > When we settled on underscores, my one reservation was that we''d keep > running into this particular problem - RSpec''s method_missing > conflicting with others. > > I have a proposition that preserves the underscore syntax, makes some > examples even more clear, and eliminates this problem once and for > all. > > 1. Eliminate reliance on method missing to handle expectations by > adding all of the documented should_x_y_z methods directly to Object. > These would all delegate off to Spec::Expectations::Should, ::Not, > ::Have, etc, so the design wouldn''t change much and Object itself, > though bloated w/ methods, would not be bloated w/ implementation. > > This would also give us a single expectations module that we add to > Object, providing several benefits including: > # more clarity in the API > # a place to put meaningful rdoc > # a potential formal plugin point >Good> 2. Change should_be to ONLY handle arbitrary predicates (not serve as > an alias for should_equal): >What would I say instead of flag.should_be true flag.should == true ?> subject.should_be :empty => passes if subject.empty? > subject.should_be :instance_of, SomeClass => passes if > subject.instance_of? SomeClass > etc... > > In my opinion (feel free to disagree), this actually makes these > examples more readable. Consider these two: > > @bdd_framework.should_be_adopted_quickly #current > @bdd_framework.should_be :adopted_quickly #proposed >I prefer the latter too> In my view, these read equally well from a language perspective AND > they make it easier for a developer to mentally separate the > expectation (should_be) from the expected value (adopted_quickly?). > > This WOULD require changes to existing specs. I think for those of you > who don''t wrap expectation args in parens that a trivial script would > handle this for you. If you do use parens, the script might be more > complex. Perhaps if we *do* choose this direction, one of you would > like to contribute such a script. > > I fully recognize that this would cause some pain, but it is my > feeling that not addressing this leaves us in a crippled position in > which we commit to being sidetracked by this issue constantly > returning instead of focusing on enhancing the API. > > I also think that this is a better option than any of the following > that also crossed my mind: > * revert to dots > * figure out a sexy way to intercept all attempts to rewrite method > missing and re-inject RSpec''s method missing in its place (perhaps > this does sound sexy, but I doth believe that there is a venereal > disease hiding in its midst) > * leave things as they are and continue to add ugly hacks like > NilClass.handle_underscores_for_rspec! (that''s MY ugly hack so I get > so call it that) > * hang myself from the nearest bridge >Fortunately Illinois is quite flat. All of these are lame options.> Of course, if you have any solutions to propose, I''m all eyes. > > Thoughts? >I think this all sounds good. It would be great to lose our method_missing. It''s not future-proof. Aslak> Thanks, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Nov 20, 2006, at 4:00 PM, aslak hellesoy wrote:>> @bdd_framework.should_be_adopted_quickly #current >> @bdd_framework.should_be :adopted_quickly #proposed >> > > I prefer the latter tooDude +1, the latter is so preferred. cheers, Olle
On 11/20/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:> On 11/19/06, David Chelimsky <dchelimsky at gmail.com> wrote: > > All, > > > > If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > > you''ll see that Chad (the submitter) found the source of the bug. > > Unfortunately, the source of *this* bug is the *solution* to a > > *previous bug* in which Rails was replacing RSpec''s method missing > > with its own. > > > > When we settled on underscores, my one reservation was that we''d keep > > running into this particular problem - RSpec''s method_missing > > conflicting with others. > > > > I have a proposition that preserves the underscore syntax, makes some > > examples even more clear, and eliminates this problem once and for > > all. > > > > 1. Eliminate reliance on method missing to handle expectations by > > adding all of the documented should_x_y_z methods directly to Object. > > These would all delegate off to Spec::Expectations::Should, ::Not, > > ::Have, etc, so the design wouldn''t change much and Object itself, > > though bloated w/ methods, would not be bloated w/ implementation. > > > > This would also give us a single expectations module that we add to > > Object, providing several benefits including: > > # more clarity in the API > > # a place to put meaningful rdoc > > # a potential formal plugin point > > > > Good > > > 2. Change should_be to ONLY handle arbitrary predicates (not serve as > > an alias for should_equal): > > > > What would I say instead of flag.should_be true > flag.should == trueActually, should_be is currently an alias for should_equal. We could let it continue to be so for everything but a symbol, in which case it would find a matching predicate method on the target. This would lead to: subject.should_be true subject.should_be false subject.should_be nil subject.should_be :using_a_symbol #subject.using_a_symbol? etc> > ? > > > subject.should_be :empty => passes if subject.empty? > > subject.should_be :instance_of, SomeClass => passes if > > subject.instance_of? SomeClass > > etc... > > > > In my opinion (feel free to disagree), this actually makes these > > examples more readable. Consider these two: > > > > @bdd_framework.should_be_adopted_quickly #current > > @bdd_framework.should_be :adopted_quickly #proposed > > > > I prefer the latter too > > > In my view, these read equally well from a language perspective AND > > they make it easier for a developer to mentally separate the > > expectation (should_be) from the expected value (adopted_quickly?). > > > > This WOULD require changes to existing specs. I think for those of you > > who don''t wrap expectation args in parens that a trivial script would > > handle this for you. If you do use parens, the script might be more > > complex. Perhaps if we *do* choose this direction, one of you would > > like to contribute such a script. > > > > I fully recognize that this would cause some pain, but it is my > > feeling that not addressing this leaves us in a crippled position in > > which we commit to being sidetracked by this issue constantly > > returning instead of focusing on enhancing the API. > > > > I also think that this is a better option than any of the following > > that also crossed my mind: > > * revert to dots > > * figure out a sexy way to intercept all attempts to rewrite method > > missing and re-inject RSpec''s method missing in its place (perhaps > > this does sound sexy, but I doth believe that there is a venereal > > disease hiding in its midst) > > * leave things as they are and continue to add ugly hacks like > > NilClass.handle_underscores_for_rspec! (that''s MY ugly hack so I get > > so call it that) > > * hang myself from the nearest bridge > > > > Fortunately Illinois is quite flat. All of these are lame options. > > > Of course, if you have any solutions to propose, I''m all eyes. > > > > Thoughts? > > > > I think this all sounds good. It would be great to lose our > method_missing. It''s not future-proof.It''s not even present proof! Thanks, David> > Aslak > > > Thanks, > > David > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On 11/20/06, Olle Jonsson <olle at olleolleolle.dk> wrote:> > On Nov 20, 2006, at 4:00 PM, aslak hellesoy wrote: > > >> @bdd_framework.should_be_adopted_quickly #current > >> @bdd_framework.should_be :adopted_quickly #proposed > >> > > > > I prefer the latter too > > Dude +1, the latter is so preferred.I''m mostly indifferent/favoring the proposed changes, but note that for the above example, might it be confusing to drop the punctuation? @bdd_framework.should_be :adopted_quickly vs @bdd_framework.should_be :adopted_quickly? I know it''s the readability of the expectation here -- you''re making a statement, so you don''t want it to end in a query, but the symbol-based approach reminds me of using Object#send(:symbol), so there''s a tiny bit of magic in appending the query for you. Perhaps the should_be helper could be a special case that could use ''.'' or some other syntax for predicate methods? I also happen to like the underscore approach in the case of things like " array.should_be_empty" to test for "array.empty? == true". But I''d concede that syntax if we could settle on something else. Maybe I just need to retrain my own eyes to be more accepting of "array.should_be :empty". Is it just me? /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/420ddf3b/attachment-0001.html
> >> @bdd_framework.should_be_adopted_quickly #current > > >> @bdd_framework.should_be :adopted_quickly #proposed > > >> > > > > > > I prefer the latter too > > > > Dude +1, the latter is so preferred. > >symbol arguments ++ for sure! I''m mostly indifferent/favoring the proposed changes, but note that for the> above example, might it be confusing to drop the punctuation? > > @bdd_framework.should_be :adopted_quickly vs @bdd_framework.should_be > :adopted_quickly? > >Nick''s point is interesting - automatically adding the ''?'' seems a little magical. But the more I think about it, the more it seems like the right thing to do. If I want to expect a value from a non-question-mark method, I can always write: my_object.method_without_question_mark.should_be true Which is a little clearer, at least to me. Three cheers for no more method missing! -- Chris Anderson http://jchris.mfdz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/bb2870a6/attachment.html
Nick Sieger wrote:> I also happen to like the underscore approach in the case of things like > "array.should_be_empty" to test for "array.empty? == true". But I''d > concede that syntax if we could settle on something else. Maybe I just > need to retrain my own eyes to be more accepting of " array.should_be > :empty". Is it just me?No, I like .should_be_empty and its ilk too... but I understand that method_missing is a huge can of worms, so I''ll sadly give it up if it makes the code more stable and gives the guys more time to work on stuff like integration testing! Jay