enable keeping matched expressions. #1308
Conversation
…e is disabled. Allows for multiple uses in a row without being too noisy
| @@ -136,11 +138,16 @@ public CoreMapExpressionExtractor(Env env) { | |||
| this.tokensAnnotationKey = EnvLookup.getDefaultTokensAnnotationKey(env); | |||
| if (env != null) { | |||
| this.collapseExtractionRules = Objects.equals((Boolean) env.get("collapseExtractionRules"), true); | |||
| this.keepNestedMatches = Objects.equals((Boolean) env.get("keepNestedMatches"), true); | |||
There was a problem hiding this comment.
The truth is, I know almost nothing about tokensregex, and I would say the people still at Stanford are generally in the same boat. Why is it necessary to use Objects.equals here? I see that it was done for a different Boolean earlier as well
There was a problem hiding this comment.
also, should the default be false instead? that way the behavior doesn't change for existing use cases
|
In general I don't see any reason not to merge this, but just to confirm, the default settings means it won't change behavior for any existing tokensregex? |
|
Ping? |
| @@ -277,6 +277,10 @@ public String getText() { | |||
| return text; | |||
| } | |||
|
|
|||
| public String getName() { | |||
|
Sorry I don't use Github enough, and as a result this went very stale. Yes the intent was to not change default behavior, rather just add some functionality to the match expression. My use was such that I wanted to use the match expressions more on their own, so I wanted to keep overlapping expressions. This next week I can look at this again and see what additional changes may be needed or reviewed. |
All edits are part of the public domain.
This provides more flexibility to the CoreMapExpressionExtractor and the matches returned. I have a use case where I want to see all the available matches, and the name of the rule as specified in the language.
I personally am not using the CompositeRule in my work, but I applied similar updates to the CompositeRule.