[ruby-core:19232] Re: refute_{equal, match, nil, same} is not useful

On Thu, Oct 9, 2008 at 12:08 AM, Jean-Fran=E7ois Tr=E2n
<[e-mail]>wrote:

> 2008/10/8 Eric Mahurin :
>
> > I agree.  I still haven't seen a compelling argument to deprecate
> "assert"
> > and use the opposite polarity.  I prefer "assert" but I can see the val=
ue
> of
> > negating the polarity with "refute" (but I'd rather see something like
> > "fail_if" to better describe what it is doing)
>
> Yes, I also think fail_if_* are good candidates :
>
> fail_if_match =3D assert_no_match
> fail_if_nil   =3D assert_not_nil
> fail_if_equal =3D assert_not_equal
> fail_if_same  =3D assert_not_same
>
> and there can be fail_unless_* ...
>

fail_if_* and fail_unless_* aliases for all assertions seem to be a good
idea. would give unit tests a very rubyish look-and-feel ...
I would introduce them in my personal unit testing module if I had one. But
...

Designing an API, especially for a standard library, which satisfies
everyone is a very difficult task. And it comes with great responsibility.
Excentric personal stand points should be left behind. The API should be
designed in consensus of the majority of users.

Probably the best way to deal with API naming problems like these, is to
count the number of statements pro versus the statements contra and decide
upon that or make a poll on the official ruby website or let matz decide
(the last has proofed to work well in the past).

I personally am against deprecating the assert_not_* aliases without very
good reasons (they don't add to complexity, don't slow down, etc.) while I
totally support efforts for finding even better names for those methods.

As for a useful deprecation policy, I suggest only to deprecate things that
could do harm. A bunch of aliases which people like for historic reasons
can't do any harm.

-- henon
-- henon