From: Meinrad Recheis Date: 2008-10-09T08:03:12+09:00 Subject: [ruby-core:19232] Re: refute_{equal, match, nil, same} is not useful ------=_Part_83870_21994730.1223507122369 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, Oct 9, 2008 at 12:08 AM, Jean-Fran=E7ois Tr=E2n 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 ------=_Part_83870_21994730.1223507122369 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On Thu, Oct 9, 2008 at 12:08 AM= , Jean-Fran=E7ois Tr=E2n <jftran@rubyfrance.org> wrote:
2008/10/8 Eric Mahurin :

> I agree.  I still haven't seen a compelling argument to depre= cate "assert"
> and use the opposite polarity.  I prefer "assert" but I= can see the value 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 int= roduce them in my personal unit testing module if I had one. But ...

Designing an API, especially for a standard library, which satisfies ev= eryone is a very difficult task. And it comes with great responsibility. Ex= centric personal stand points should be left behind. The API should be desi= gned in consensus of the majority of users. 

Probably the best way to deal with API naming problems like these, is t= o count the number of statements pro versus the statements contra and decid= e 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 ve= ry 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 d= eprecate things that could do harm. A bunch of aliases which people like fo= r historic reasons can't do any harm.

-- henon
-- henon
------=_Part_83870_21994730.1223507122369--