[rspec-users] artificial sugar causes cancer

David Chelimsky dchelimsky at gmail.com
Mon Nov 20 11:13:08 EST 2006


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 == true

Actually, 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
>


More information about the rspec-users mailing list