Refactor SmartAnswer::Question::Base #2319
Merged
+108
−25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
floehopper
force-pushed
the
refactor-question-base
branch
from
c9116cb to
f8c206b
Compare
|
I've just rebased this against master, added one extra commit on the end, and force-pushed. It is again ready for review. |
floehopper
force-pushed
the
refactor-question-base
branch
from
f8c206b to
6e26664
Compare
|
I've just rebased this against master, added a couple of small commits, and force-pushed. |
|
@chrisroos: Can you review this when you have a chance? I'm basing another branch on the changes in this one, so it would be good to get feedback on it as soon as possible. The changes in this one are all pretty minor. |
|
Other than the question about the change from Also, might be worth verifying that the existing documentation on |
|
@erikse: Thanks. I'll have a look to see whether any of the docs need updating. |
|
I've just pushed some updates/improvements to the docs for |
|
I'm going to rebase this against master and force-push in preparation for merging. |
Nothing seems to be relying on the "writer" behaviour of this method. Furthermore, I think that this kind of dual-purpose method (both reader and writer) are confusing. So by converting the method into an attribute reader, we're simplifying the code.
This method does not appear to be used anywhere.
The name `default_next_node_function` confused me for two reasons: 1. The instance variable doesn't just store the *default* value; it also stores non-default values. 2. It's more common to talk about methods and blocks in Ruby rather than functions. In this case, the instance variable stores a reference to a block.
I don't think this method was adding anything to the code.
* Consistently use `ArgumentError` if `next_node` is called with incorrect arguments. * Add unit test coverage for the two possible errors. * Add/improve error messages.
There's nowhere else these instance variables could've been assigned prior to the class' constructor, so it doesn't seem necessary to include the `||` check to see whether they are already assigned.
* Calls to `lambda` produce less surprising procs than calls to `proc` or `Proc.new` (in terms of their return behaviour). * Procs produced by calls to `lambda` are stricter about the number of arguments they are passed and so we have to declare a dummy input argument like we do in the constructor. * We were already using `lambda` to set the default value of `@next_node_block` in the constructor and it seems better to be consistent.
There are two ways that a `NextNodeUndefined` exception can be raised: 1. The call to `next_node` does not return a truth-y value 2. No call to `next_node` is made The second of these was not being unit tested.
In the case where no call to `next_node` is made for a question, the code which raises `NextNodeUndefined` relies on the default value for `@next_node_block` returning a false-y value when invoked. This makes that more explicit.
I think this improves the readability, because the line is so long it's easy to miss the conditional. Also it's consistent with the `if` statement immediately below it.
I'm pretty sure we don't have any places where `next_node` is called multiple times per question and I can't see any sensible justification for allowing it. Constraining the DSL so that it can only be called once means that we can simplify the code and make it easier to reason about. With this guard condition in place, there's no longer any need to add the `permitted_next_nodes` to any stored in a previous call.
Previously we were relying on detecting a side-effect of `next_node` having been called previously. Now we rely on whether or not `@next_node_block` has been set which is much more direct and explicit.
Also added full-stop to second sentence for consistency.
Most of these changes document behaviour that existed prior to this pull request, although some of the error messages have changed slightly. The only additional behaviour that was added in this pull request is the check which prevents multiple calls to `next_node`.
floehopper
force-pushed
the
refactor-question-base
branch
from
3a59c2b to
f441f7c
Compare
floehopper
added a commit
that referenced
this pull request
Mar 7, 2016
Refactor SmartAnswer::Question::Base
|
This looks good to me |
This was referenced Mar 7, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These changes were prompted by me preparing the ground for a new version of #2311.
There are still lots of improvements that could be made to this code, but I think the changes in this PR should make the work I want to do on automatic detection of permitted next nodes easier.