From: SASADA Koichi <ko1@...>
Date: 2008-09-25T17:19:58+09:00
Subject: [ruby-core:18889] Re: [ANN] Ruby 1.9.1 feature freeze

Ryan Davis wrote:
>> For instance, I think readability of output of miniunit requires greater
>> consideration: use of pretty_inspect instead of inspect, appropriate line
>> feeds (when failure message is too long), etc.
> 
> pretty_inspect vs inspect: speed. This had a HUGE impact. If you
> override mu_pp(obj) you can change it as you deem appropriate. I
> certainly plan to for my sexp/parser code, but won't elsewhere.
> 
> appropriate line feeds: I simply didn't think about it. All the code
> I've been working on has HUGE output whether horizontal or vertical, so
> I have to use unit_diff to make it readable at all... I assume this
> mostly centers on your preference of pretty_inspect. Again, that can be
> addressed via mu_pp. I think I like leaving it up to the user so they
> can tweak as they deem appropriate. But I'm open to suggestions here.

That is one of the reasone why I proposed lazy message building.
Now we don't need more cost if the test succeeds.


>> In other instances, `assert_raise' is deprecated for unexplained reasons.
>> I think other issues will become clear during further use of miniunit.
> 
> I just saw that Nobu rolled the undeprecated name from assert_raises to
> assert_raise. Unfortunately the deprecation was NOT a typo and is
> intentional. It is both a better English word choice and it is more
> consistent with the other assertions (assert_includes, assert_throws, etc).
> 
> I've rolled Nobu's change back, pending more dialog on the topic. My
> preference is to have assert_raises and deprecate assert_raise. Barring
> that, assert_raise could be an alias and stick around for those folk who
> prefer it.

I want to ask Matz about it (naming policy).

-- 
// SASADA Koichi at atdot dot net