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

Parent & al. #16

Merged
merged 5 commits into from
Oct 11, 2018
Merged

Parent & al. #16

merged 5 commits into from
Oct 11, 2018

Conversation

marcandre
Copy link
Contributor

This PR fixes #12 by adding:

  • parent, parents & lineage as instance and singleton methods to APIPath
  • Namespace.traverse

It builds on [#15], but doesn't really depend on it.

@marcandre marcandre force-pushed the parent branch 2 times, most recently from 1f9036b to de6b887 Compare September 24, 2018 04:06
Copy link
Contributor

@zverok zverok left a comment

Choose a reason for hiding this comment

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

Thank you!
I am willing to merge this :)
Please rebase.
(I left a pair of comments, but neither is mandatory to react upon.)

result
end

def lineage
Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure about the name, never met this word used in this context :)
Are there any other gems/Ruby project that provide the same API ("me and my parents") you aware of?.. What names do they prefer?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, there's Module#ancestors, which includes the module itself... but we can't use that. It's not really mandatory. I've removed it from the PR, we can add it later if need be.

grand_child_class
]
end
end
end
Copy link
Contributor

Choose a reason for hiding this comment

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

With saharspec (already included) you can make it this way:

subject { ->(*args) { namespace_class.traverse(*args).to_a } }

its_call { is_expected.to ret [...] }
its_call(:namespaces) { is_expected.to ret [...] }
its_call(:endpoints) { is_expected.to ret [...] }
# ...and also..
its_call(:garbage) { is_expected.to raise_error ArgumentError }

(ret is matcher name for "(its call) returns")

For me, this is more DRY and expresses "what's going on" better (params difference is not hidden in the middle of example, "what is test subject" also made obvious), but I will not insist, I heard different opinions on those tricks :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, nice. Changed.

@zverok zverok merged commit 371f7b5 into molybdenum-99:master Oct 11, 2018
@zverok
Copy link
Contributor

zverok commented Oct 11, 2018

Thanks! And sorry for the delay.

@marcandre marcandre deleted the parent branch October 11, 2018 16:32
@marcandre
Copy link
Contributor Author

Cool 😸
Would it be possible to have a release?

@zverok
Copy link
Contributor

zverok commented Oct 16, 2018

Let's finish with all your open PRs discussion, and then we'll do it?

@marcandre
Copy link
Contributor Author

Lol, personally, I make a release for any new feature or bug fix. I figure it costs nothing, and avoids waiting for a PR, then there's another open, etc... and time passes by.

@zverok
Copy link
Contributor

zverok commented Oct 16, 2018

Well, with 3 open PRs on the table I prefer {discuss/merge 3 PRs}→{release} to {merge}→{release}×3.

@marcandre
Copy link
Contributor Author

marcandre commented Nov 14, 2018

@zverok here's why I prefer to make frequent releases... It's been a month (since my request) the last release is more than a year old, and there are many differences between the current code and the released code. And there are still 3 open PRs 😈

@marcandre
Copy link
Contributor Author

(Give me the access and I'll do the releases for you!)

@zverok
Copy link
Contributor

zverok commented Nov 17, 2018

Yeah, you were right, I was wrong (expecting we'll "just finalize it" in 1-2 days). But currently things are tough for me.
They'll be better.

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.

Access to parent namespace
2 participants