[ruby-core:19202] Re: [ANN] Ruby 1.9.1 feature freeze

On Wed, Oct 8, 2008 at 3:05 AM, Ryan Davis <[e-mail]> wrote=
:
> On Sep 30, 2008, at 05:24 , Dave Thomas wrote:
>> For example, the deprecations are fine in theory. But think about how
>> tests are supposed to work. You run them, and they're supposed to be sil=
ent.
>> Maybe a row of dots, but that's it. Any output means there's a problem.
> I think it is a cultural problem. We don't have or even support a culture=
 of
> deprecation, of shedding dead weight. Somehow, the idea of announcing ahe=
ad
> of time that you intend to delete code (with a suitable replacement)
> _sometime_in_the_future_ sends shockwaves of terror throughout the ruby
> community. Personally, I find that rather embarrassing as I see nothing
> better than to reduce the amount of cruft we have and still maintain
> functionality.

I don't agree on several levels. This isn't merely about saying that
you're going to delete code in the future. It's the level of output.
When I was deprecating a mistake in one of my libraries, I did so over
three versions. The first version printed a warning the very first
time a deprecated feature was used and not after that. The second
version printed a warning every time a deprecated feature was used.
The third version removed the feature.

The change that's here now prints a message every time.

>> But now, when I run my tests, I get pages of stuff flying by, saying stu=
ff
>> is deprecated. To someone who lives by tests, this is incredibly scary.
>>
>> You might say "change your tests". But I think that's being a little
>> harsh. Part of being compatible with Test::Unit is providing a similar
>> user-level experience to it. A minor heart attack the first time you run=
 is
>> a different experience.
> Except... we're talking about a __DOT-OH__ release. If this was 1.6.9 I'd
> completely agree, but this is 1.9.0 and we've had no problems with
> incompatibilities thus far. Think about the number of tests that are goin=
g
> to fail that expect String#[n] to return an int that are now going to blo=
w
> up. Somehow that's OK, yet deprecating poorly named API is not? No. Dot-O=
hs
> are where we introduce our incompatibilities.

You're the only person that I've seen claiming that "assert_not_*" is
poorly named *and* that "refute_*" is a better name. You might not
like arguing semantics, but you're making a semantic decision for the
rest of us. Personally, I don't even think it has to come down to
semantic distinctions, even though I've already made clear why I think
that "refute_*" fails the semantic test.

If I don't know the entire Ruby unit test API, but I know that
"assert_equal" exists, I can reasonably guess that a negative test
would be called "assert_not_equal" because of consistency in naming
conventions. Never in a million years would I guess "refute_*", even
for looking up the method in the documentation. How am I supposed to
find that negative assertions begin with "refute_*"?

String#[] isn't exactly a great choice for comparison: a lot of people
who are new to Ruby find the 1.8 behaviour disconcerting because
they're used to other languages. There's also a good reason for the
change: we're making Ruby far more functional. I'm not at all
convinced that "refute_*" is a more functional or more meaningful name
than "assert_not_*". I'm not likely to be convinced, either, since it
violates consistency of API.

(Just as a side note, because my day job has a lot of C++ in it, I've
surveyed most of the C++ unit test frameworks out there. Some of them
are pretty out there in terms of how they do things, but all of them,
including the newest one from Google, use some form of ASSERT_* and no
one uses REFUTE_*. By switching to refute_*,  you're making it harder
for people to migrate from other languages to Ruby, with what I see as
no good reason.)

> And in this case, we're not even talking actual breakage... that's the th=
ing
> that is killing me. We're talking about 100% compatible API, telling you
> that you're going to need to change it in the future. I even documented W=
HEN
> I was going to do this and nothing is even remotely close (or etched in
> stone for that matter):

It's not 100% compatible if there's a warning thrown where there
didn't used to be -- especially if that warning is thrown on every
call on something as high-traffic as tests.

Martin D=FCrst suggested that, if you insist upon deprecating
assert_not_*, you only print the message once, matches my experience
with deprecating things in my own libraries. Next version, switch it
to printing on every use.

> Yet, somehow, this is a huge thing that is totally freaking everyone out.=
 I
> just don't get it at all, esp. given how long this has been in the works =
and
> how shockingly little feedback there was that whole time.

Maybe it's because I don't follow ruby-talk anymore (because of the
volume), but I had no reason or opportunity to play with miniunit,
much less a test/unit shim. I suspect that the answer for a lot of
people would be similar regarding reason and opportunity.

-austin
--=20
Austin Ziegler * [e-mail] * http://www.halostatue.ca/
               * [e-mail] * http://www.halostatue.ca/feed/
               * [e-mail]