Skip to content

circular-buffer: Clarify overwrite #892

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

Merged
merged 2 commits into from
Sep 7, 2017
Merged

circular-buffer: Clarify overwrite #892

merged 2 commits into from
Sep 7, 2017

Conversation

shaleh
Copy link

@shaleh shaleh commented Sep 7, 2017

This pull request is in two pieces in case the change to the test cases is controversial.

The description change is to make overwrite clear for the reader. To this end another example is added and that there is a difference in behaviour when the buffer is not full.

In the test cases descriptions I exchanged the word "replace" for the word "remove". This should add clarity especially for the readers who are not native English speakers.

Sean 'Shaleh' Perry added 2 commits September 7, 2017 11:12
Overwrite replaces the oldest item in the buffer if the buffer is
empty. Otherwise it is just like write. This commit documents what
overwrite on a buffer with available space looks like and clarifies
what the oldest element is after an overwrite operation succeeds.

Closes: 889
As discussed in exercism#889, the documentation for the overwrite operation
was vague. overwrite replaces the oldest element in the buffer if the
buffer is full and is just a normal write if there is space available.
Copy link
Member

@tleen tleen left a comment

Choose a reason for hiding this comment

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

The only comment I have is about the comment, I believe GitHub only auto closes issues if it is written using the '#' in front of it (and no ':'): "Closes #889". No big deal here though. 👍

@tleen tleen merged commit dea5801 into exercism:master Sep 7, 2017
@shaleh
Copy link
Author

shaleh commented Sep 7, 2017

Ah, thanks. Sorry about that.

@shaleh
Copy link
Author

shaleh commented Sep 7, 2017

A CI check which complains about such minor things could save some hassle.

@tleen
Copy link
Member

tleen commented Sep 7, 2017

NP, I fixed it in the commit message. GitHub specific Git takes some getting used to!
I think a CI check could totally false positive too, which could be worse than not having it?

@shaleh
Copy link
Author

shaleh commented Sep 7, 2017

At various employers I have seen it work well. It really depends on if the over head from the commits is high enough to offload the problem on the submitters instead of the committers.

shaleh pushed a commit to shaleh/exercism-problem-specifications that referenced this pull request Sep 21, 2017
As discussed in exercism#889, the documentation for the overwrite operation
was vague. overwrite replaces the oldest element in the buffer if the
buffer is full and is just a normal write if there is space available.

Overwrite replaces the oldest item in the buffer if the buffer is
empty. Otherwise it is just like write. This commit documents what
overwrite on a buffer with available space looks like and clarifies
what the oldest element is after an overwrite operation succeeds.

Closes exercism#889
petertseng added a commit to exercism/rust that referenced this pull request Nov 18, 2018
The tests are the same as the initial unversioned version of canonical-data:
exercism/problem-specifications#488

This is because all subsequent changes did not change test content:

1.0.0 (formatting change only):
exercism/problem-specifications#681
1.0.1 (clarify overwrite):
exercism/problem-specifications#892
1.1.0 (move inputs to `input` object):
exercism/problem-specifications#1186

The Rust track already had most of the tests; these mostly add some
clarity around `clear` and addds a test for an `overwrite` following a
`read`.
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