Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce reference of IO globals #500

Merged
merged 1 commit into from
Dec 31, 2015
Merged

Reduce reference of IO globals #500

merged 1 commit into from
Dec 31, 2015

Conversation

mbj
Copy link
Owner

@mbj mbj commented Nov 22, 2015

No description provided.

@mbj mbj force-pushed the fix/reduce-globals branch 2 times, most recently from 8d6cda4 to 3cea008 Compare November 22, 2015 00:08
@mbj
Copy link
Owner Author

mbj commented Nov 22, 2015

@dkubb Ready for review after #499, sorry for this chain of dependent PRs, but it makes more sense to base this change on top of the global style fix in #499.

@mbj
Copy link
Owner Author

mbj commented Nov 22, 2015

IMHO this approach seems like a mistake. Naming the option with the same name as the core class should be a clear signal this is less than ideal.

I agree that the state this PR is resulting in is clearly showing a smell. Still I think this state is better than before:

The PR addresses the problem that mutant at various location interacted with IO globals, and the only way to spec these was A): Running the IO operation and observing the mostly global state change B) hooking the IO global via a message expectation, resulting in observable inconsistencies under parallelization (rspec does not do this, but xspec will!)

I think a better approach, here and below, would be to make a simple object that provides a limited interface and uses the core class.

Exactly. That is planned at the next step. But before I want to "lift" the IO globals into the config object, to get a clear "index" on what the wrapping class needs to provide. See this PR as a small intermediary.

Sure, this design allows you to inject the core class in specs, but I think this is taking dependency injection too far. I could be wrong about this, but I think you'll find this approach is a dead-end, and a limited scope wrapper is a much cleaner approach long term.

Its much easier to go from "config object holds globals" to "we have a mutant specific IO object we can pass around" than from "IO globals are everywhere" to the desired state.

There will be some other PRs that reduce more IO global use, the code base still references $stderr and File from classes that do not yet keep state. Fixing these to use the config is the next step, than coming up with the "mutant specific IO wrapper" we discussed.

With that arguments: @dkubb Ready for the next pass.

@dkubb dkubb force-pushed the fix/reduce-globals branch 2 times, most recently from c4c887e to ba07692 Compare November 23, 2015 07:30
@@ -204,7 +204,11 @@ class Config
integration: Integration::Null,
isolation: Mutant::Isolation::Fork,
jobs: Mutant.ci? ? CI_DEFAULT_PROCESSOR_COUNT : ::Parallel.processor_count,
kernel: Kernel,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you've audited the code to make sure it doesn't refer to anything outside of the Mutant namespace, besides here of course?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No direct references to Kernel exist inside the mutant namespaces anymore, correct. But other IO globals are still referenced and need future iterations, this PR is only the first step.

I extracted this PR out of a bigger change, as other changes need refactorings to be applied first.

@dkubb
Copy link
Collaborator

dkubb commented Nov 23, 2015

@mbj I finished a pass over this code.

@mbj
Copy link
Owner Author

mbj commented Nov 23, 2015

@dkubb Ready for the next pass.

@@ -153,14 +164,14 @@ def add_debug_options(opts)
end
opts.on('--version', 'Print mutants version') do
puts("mutant-#{VERSION}")
Kernel.exit(EXIT_SUCCESS)
config.kernel.exit(EXIT_SUCCESS)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the default status code for Kernel.exit success? If so, then the EXIT_SUCCESS argument isn't required.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, good catch

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to remove the EXIT_SUCCESS constant altogether?

@dkubb dkubb force-pushed the fix/reduce-globals branch 2 times, most recently from ba22f2b to 8d4c326 Compare November 24, 2015 05:35
@dkubb
Copy link
Collaborator

dkubb commented Nov 24, 2015

@mbj I finished a pass over this PR.

@mbj mbj force-pushed the fix/reduce-globals branch 5 times, most recently from 432f03c to 540edf8 Compare December 19, 2015 22:02
@mbj
Copy link
Owner Author

mbj commented Dec 20, 2015

Depends on #508

@mbj mbj force-pushed the fix/reduce-globals branch 2 times, most recently from 59e81fb to 5262a1e Compare December 20, 2015 19:28
@mbj mbj force-pushed the fix/reduce-globals branch 6 times, most recently from e74414f to 9194723 Compare December 21, 2015 01:32
@backus
Copy link
Contributor

backus commented Dec 24, 2015

I noted remaining globals as I looked through mutant. I don't think this is exhaustive and it doesn't cover implicit usage like with Kernel:

  • Mutex and ConditionVariable in mailbox.rb
  • File and IO references in isolation.rb
  • Object references in expression/method.rb, expression/methods.rb, expression/namespace.rb
  • Marshall in isolation.rb
  • ObjectSpace in env/bootstrap.rb
  • Open3 in cli/tput.rb
  • OptionParser in cli.rb
  • Regexp in expression/namespace and mutant/mutator/node/named_value/variable_assignment.rb
  • Digest::SHA1 in mutation.rb
  • Set in mutator, parallel/master, and zombifier.rb
  • StringIO in reporter/cli/format
  • Time in env.rb, integration/rspec.rb, and runner/sink.rb

@mbj
Copy link
Owner Author

mbj commented Dec 24, 2015

@backus Yeah, I'm ware this PR is not exhaustive. Its intend to slice small portions each time I find motivations. In xspec I do not want to support setting message expectations on anything else than doubles hence over the time we need to eradicate all the globals we use and set message expectations on.

So not all of the globals in your list have to be changed, as there are AFAIK no message expectations on for example Set.

@backus
Copy link
Contributor

backus commented Dec 25, 2015

Yeah, I'm ware this PR is not exhaustive.

Ah yeah I understood that. I just wanted to have some idea of what is still left and I also wanted to know if you are actually planning to kill all of these constant references too.

@mbj
Copy link
Owner Author

mbj commented Dec 25, 2015

I also wanted to know if you are actually planning to kill all of these constant references too.

Longterm yes.Currently I cut the iteration into a small one to get it merged as an iterative improvement before it grew to big. I'll do followups to focus on the globals I've to place message expectations on. This is the blocker for making mutant hosted on xspec.

I just wanted to have some idea of what is still left

NP

@dkubb
Copy link
Collaborator

dkubb commented Dec 28, 2015

@mbj I will be ready to merge this once #508 is merged.

@@ -13,7 +13,11 @@ class Config
:includes,
:isolation,
:jobs,
:kernel,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mbj not a blocker, but should this Array of Symbols be defined using %i[...]?

dkubb added a commit that referenced this pull request Dec 31, 2015
Reduce reference of IO globals
@dkubb dkubb merged commit b2207da into master Dec 31, 2015
@dkubb dkubb deleted the fix/reduce-globals branch December 31, 2015 19:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants