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

Enable warnings during spec execution and fix warnings #110

Merged
merged 9 commits into from
Dec 23, 2016
Merged

Enable warnings during spec execution and fix warnings #110

merged 9 commits into from
Dec 23, 2016

Conversation

ivoanjo
Copy link
Contributor

@ivoanjo ivoanjo commented Dec 21, 2016

This PR fixes all warnings from Hyperclient code during spec execution.

@dblock
Copy link
Collaborator

dblock commented Dec 21, 2016

Can you rebase this? I am a little uncomfortable with the whole forward declaration thing though, is that avoidable?

@ivoanjo
Copy link
Contributor Author

ivoanjo commented Dec 21, 2016

I've rebased with the current master 😄

As for the forward declaration, it indeed is a strange problem. In terms of opening classes twice, ruby has no troubles with it, and since Hyperclient doesn't do any strange meta things --- while it's being loaded no part of the code tries to use a Resource instance --- and thus it's a bit hard to get bitten, as you'd have to be doing really strange things such as requiring in a thread while trying to use hyperclient on other thread concurrently.

As for alternatives, the problem here is that we need to have something that the other files can check in order to stop the circular require. So we could set some kind of constant (instead of the class itself) that said "class has been / is in the process of being required", so that you'd then have

# in resource.rb
module Hyperclient
  RESOURCE_AVOID_CIRCULAR_REQUIRE = true
end

require 'some other file'

# in other files
require 'resource' unless defined? Hyperclient::RESOURCE_AVOID_CIRCULAR_REQUIRE

Another alternative would be instead of having a small predeclaration of the class at the beginning of the file, you could just move the requires to the end of the class (maybe leave a note at the top # note: requires at the bottom to avoid circular requires), and thus the whole class would be defined before the require operations.

This approach is feasible because you're not running any of the class code during definition, so it's ok to refer in advance to things that haven't been defined yet (you'll get an error if they aren't defined by the time the code tries to run).

Do you think any of these alternatives are better? I can also remove that commit too, if you're unconvinced with either 👍

@dblock
Copy link
Collaborator

dblock commented Dec 21, 2016

I think either lib/hyperclient/resource.rb should not require anything and we just know that they are required elsewhere, or better, move all requires into a parent file, like hyperclient.rb?

@ivoanjo
Copy link
Contributor Author

ivoanjo commented Dec 21, 2016

Ah, yes indeed. I'm a fan of "require what you use" (thus I didn't really think of just having it all in one place), but that approach would also solve the problem entirely. Shall I update the PR with that approach?

@dblock
Copy link
Collaborator

dblock commented Dec 22, 2016

Yes please, that seems a lot cleaner.

Ivo Anjo added 3 commits December 23, 2016 11:05
The Resource class references LinkCollection (which references Link) and
ResourceCollection and both Link and ResourceCollection reference
Resource. Because each class required what it referenced, this created
a circular require cycle (which ruby works around, but also issues an
warning).

To fix this, this commit moves all requires to the `hyperclient.rb`, thus
making sure we only require files once and avoid any cycles.

Thanks @dblock for suggesting this approach.
@ivoanjo
Copy link
Contributor Author

ivoanjo commented Dec 23, 2016

@dblock done 😄 and happy holidays ☃️

@dblock dblock merged commit 6735375 into codegram:master Dec 23, 2016
@dblock
Copy link
Collaborator

dblock commented Dec 23, 2016

Merged, thank you.

@ivoanjo
Copy link
Contributor Author

ivoanjo commented Dec 23, 2016

Awesome! Looking forward to the next release :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants