From: eregontp@... Date: 2016-03-27T12:15:11+00:00 Subject: [ruby-core:74606] [Ruby trunk Bug#12220] Why does Coverage keep previously-loaded files as empty arrays? Issue #12220 has been updated by Benoit Daloze. Yusuke Endoh wrote: Thank you for your answer! > I don't care the behavior of restarting coverage because I have no actual use case. Do you have any? I don't think that ruby/spec is. Indeed, although tests usually improve the design of an API. > This module is considered professional-use. With regard to this module, intuition is not important to me, unless there is actual use case. I think the current behavior is more confusing than helping, so the use case would be "avoid unexpected behavior :)". > From the beginning, I had given up making this module "intuitive". I think the most intuitive usage is (1) requiring all modules, next (2) call `Coverage.start`, (3) do the main task, and finally (4) call `Coverage.result` and save the result. But it is impossible because of an implementation restriction (the compiler does not insert trace instructions by default because of its overhead). This is fine as a limitation of the module, no objection to that. > > If not, would it be OK to clear the Hash when calling #result? > > As I recall correctly, the first implementation did so, but the behavior changed by an ticket #4796. I don't recall why it is needed, but the OP seemed to think it useful. It seems to be an unintended side-effect of your patch in #4796. By "restartable", I think most people would expect an initial state again (no coverage info, so an empty Hash or Qundef internally). Then the pair Coverage.start/Coverage.result truly allow to restart/reset and Coverage.peek_result allows to read the current state. That seems like a good API, and as far as I can see the only change would be to fully reset coverage data on Coverage.result. I'll attach a patch. ---------------------------------------- Bug #12220: Why does Coverage keep previously-loaded files as empty arrays? https://bugs.ruby-lang.org/issues/12220#change-57733 * Author: Benoit Daloze * Status: Open * Priority: Normal * Assignee: Yusuke Endoh * ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux] * Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN ---------------------------------------- For instance, ruby -e 'require "coverage"; Coverage.start; require "set"; Coverage.result; Coverage.start; require "tmpdir"; p Coverage.result' {".../lib/ruby/2.2.0/set.rb"=>[], ".../lib/ruby/2.2.0/tmpdir.rb"=>[nil, nil, nil, nil, nil, nil, 1, 1, ...]} So Coverage.result stops coverage but also does some cleaning up. I think the most intuitive would be that the coverage Hash would be reset to be empty, but instead it's filled with empty arrays. As an example, this makes it fairly awkward to test and it enforces irreversible global state (https://github.com/ruby/spec/pull/219). I also do not see how this would be useful for coverage libraries. Is there a reason for this behavior? If not, would it be OK to clear the Hash when calling #result? -- https://bugs.ruby-lang.org/ Unsubscribe: