Skip to content

grade-school: Expect Option<Vec<String>> from grade; add stub file #256

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
Feb 13, 2017
Merged

grade-school: Expect Option<Vec<String>> from grade; add stub file #256

merged 2 commits into from
Feb 13, 2017

Conversation

petertseng
Copy link
Member

Previously, grade was expected to return an Option<&Vec<String>>.
Because there's a reference inside the lifetime, any implementing School
would have been required to maintain ownership of some vectors so that
they can be lended out. This unnecessarily restricts the implementation.
For example, some implementations may instead have preferred to use
BTreeSet.

If we expect grade to return Option<Vec<String>>, the fact that
ownership is given means that a new vector can be made from whatever
internal representation is used.

Closes #254.

Previously, grade was expected to return an `Option<&Vec<String>>`.
Because there's a reference inside the lifetime, any implementing School
would have been required to maintain ownership of some vectors so that
they can be lended out. This unnecessarily restricts the implementation.
For example, some implementations may instead have preferred to use
BTreeSet.

If we expect grade to return `Option<Vec<String>>`, the fact that
ownership is given means that a new vector can be made from whatever
internal representation is used.

Closes #254.
@petertseng petertseng changed the title grade-school: Expect Option<Vec<String>> from grade grade-school: Expect Option<Vec<String>> from grade; add stub file Feb 2, 2017
@pviecelli
Copy link

Thanks! That makes more sense now! :)

unimplemented!()
}

pub fn grade(&self, grade: u32) -> Option<Vec<String>> {
Copy link
Member Author

@petertseng petertseng Feb 3, 2017

Choose a reason for hiding this comment

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

#254 (comment)

It would be nice if, when a constraining choice like this is made, the README or stub file could be explicit about why that interface was chosen.

I failed to do this. It could be something like "If grade returned an Option<&Vec<String>>, the internal implementation would be forced to keep a Vec<String> to lend out. By returning an owned vector instead, the internal implementation is free to use whatever it chooses." This is your chance to suggest whether this text should be added as a comment, or something else.

As indicated in #117 and #200, we prefer to have stub files.
@petertseng
Copy link
Member Author

Ten days, one definite vote that this improves things, and no objections. I'm merging it.

@petertseng petertseng merged commit 5bea345 into exercism:master Feb 13, 2017
@petertseng petertseng deleted the grade-school branch February 13, 2017 01:23
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