rspec users - Nov 2006 - underscores, sugar, and more and more bugs

I sent this earlier under with the subject "artificial sugar causes
cancer" and I think some spam filters ate it. Here it is again:
=====================================
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:
>
> I sent this earlier under with the subject "artificial sugar causes
> cancer" and I think some spam filters ate it. Here it is again:
> =====================================>
> 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

I was looking through Dave Astel''s Mastermind tutorial. In it he had
the
method win?
  should_be :win
seems clunky. I suppose that should_be supports past tense:
  should_be :won
and should supports present tense:
  should :win

Regarding the adopted_quickly example its:
  should_be :adopted_quickly
and
  should :adopt_quickly

I imagine that most of these boolean (?) methods are in present tense.

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
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20061120/0ca85cea/attachment-0001.html

On 11/20/06, Brian Takita <brian.takita at gmail.com>
wrote:
>
> On 11/19/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> > I sent this earlier under with the subject "artificial sugar
causes
> > cancer" and I think some spam filters ate it. Here it is again:
> > =====================================> >
> > 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
>
>
> I was looking through Dave Astel''s Mastermind tutorial. In it he
had the
> method win?
>   should_be :win
> seems clunky. I suppose that should_be supports past tense:
>   should_be :won
> and should supports present tense:
>   should :win
>
> Regarding the adopted_quickly example its:
>   should_be :adopted_quickly
> and
>   should :adopt_quickly
>
It also looks like should_be works with adjectives and past tense verbs with
adverbs.
  should be black?
  should be adopted quickly?

should seems to support using present tense verbs posed as a question.
  should adopt?

I apologize if this is old stuff that was already discussed.

I imagine that most of these boolean (?) methods are in present
tense.
>
> 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
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20061120/70ec1fa9/attachment.html