Conversation
… efficient) refactoring
monsterkrampe
left a comment
monsterkrampe
left a comment
There was a problem hiding this comment.
Looks nice overall. I left some specific comments again :)
| special_edge_cycles | ||
| } | ||
|
|
||
| fn edge_is_special(&self, node: &Position<'a>, next_node: &Position<'a>) -> bool { |
There was a problem hiding this comment.
I think there is kind of a convention to have methods returning bool named as is_... or at least have them start with a verb (is, contains, ...). That is, I would go for is_edge_special here. (This reminds me of ruby's convention, where this method would probably be called edge_special?.)
| .any(|cycle| self.cycle_contains_special_edge(cycle)) | ||
| } | ||
|
|
||
| fn cycle_contains_special_edge(&self, cycle: &Cycle<Position<'a>>) -> bool { |
There was a problem hiding this comment.
Similar to the comment below, I think contains_special_edge_in_cycle would be a better name.
| } | ||
|
|
||
| /// Returns the common marking of a RuleSet. | ||
| pub fn build_and_check_marking(&self) -> Option<Positions> { |
There was a problem hiding this comment.
I think it would be good if the method names (at least for the public methods) would somehow indicate what this marking is for. I assume it's for the sticky check? Maybe also it would be worthwhile to rename occurrences of "Marking" to "StickyMarking" but I'm less sure about that...
| } | ||
| } | ||
|
|
||
| trait AffectedPositionsBuilderPrivate<'a> { |
There was a problem hiding this comment.
The capabilities described by this trait are not really a builder pattern.
Maybe I would call this trait AffectedPositionInference because both RuleSets and Rule are "capable" of infering affected positions (possibly based on already given positions).
| } | ||
| } | ||
|
|
||
| trait AttackedPositionsBuilderPrivate<'a> { |
There was a problem hiding this comment.
Same as above and the same also applies below.
Also keep in mind in general that traits do not describe entities but capabilities. (This a bit different from interface in object oriented languages I would say.)
| pub struct RuleAndVariablePair<'a>(pub [RuleAndVariable<'a>; 2]); | ||
|
|
||
| // NOTE: KEEP? | ||
| /// This Trait provides methods to get all (HashSet<Position> / Positions) of some type. |
There was a problem hiding this comment.
To get rid of the Doc errors, I think you can put the code snippets in backticks (`).
For Example:
/// This Trait provides methods to get all (`HashSet<Position>` / `Positions`) of some type.
|
|
||
| // NOTE: KEEP? | ||
| /// This Trait provides methods to get all (HashSet<Position> / Positions) of some type. | ||
| pub trait AllPositivePositions<'a> { |
There was a problem hiding this comment.
Just because a method is implemented on two different structures does not mean that there needs to be a trait for this.
For this trait and also others in this file I would say that the functionality is too specific to justify generalizing this into a trait.
If you want to keep the trait, it needs to describe a proper capability.
Also PositivePosition should be renamed to something like PositiveLiteralPosition because it is not clear what it means for a Position to be positive.
… attacked positions or other markings to end with 'Inference'. Renamed method name for the markings for the sticky and weakly-sticky checa more clear so they can be connected to the checks.
…entialRuleAndVariables as they are not describing capabilities. Therefore, the methods are now just implemented for the specific type.
… tests. Hopefully solved errors regarding the comments
3 participants
This PR will add membership checks for various syntactic (and some semantic) classes of rule sets. The implementation is done by @xR0xEr.
(This will still take some time and I am mainly creating this Draft PR now to have a place for review and discussion.)