Skip to content

Conversation

@monsterkrampe
Copy link
Member

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.)

xR0xEr and others added 30 commits August 25, 2024 16:39
@mkroetzsch
Copy link
Member

General comment: It would be good to think about the API and UI for running these checks. I have created an issue #611 for this purpose.

Copy link
Member Author

@monsterkrampe monsterkrampe left a comment

Choose a reason for hiding this comment

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

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 {
Copy link
Member Author

Choose a reason for hiding this comment

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

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 {
Copy link
Member Author

Choose a reason for hiding this comment

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

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> {
Copy link
Member Author

Choose a reason for hiding this comment

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

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> {
Copy link
Member Author

Choose a reason for hiding this comment

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

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> {
Copy link
Member Author

Choose a reason for hiding this comment

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

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.
Copy link
Member Author

Choose a reason for hiding this comment

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

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> {
Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

4 participants