Jira (PUP-957) Case and Selector expressions using Regexp type does not set match vars

[Henrik Lindberg (JIRA)]

Title: Message Title

Henrik Lindberg commented on an issue   Re: Case and Selector expressions using Regexp type does not set match vars The issues here are: It is questionable if it is helpful that a LHS =~ RegexpType works as if the RHS was a literal Regexp since a RHS String is converted to a Regexp by the =~ operator. Strictly, a String is not an instance of Regexp - and thus, the =~ operator can not be used to tell if something is a Regexp It is correct to use a PatternType to match String vs Pattern (Pattern is based on one or more Regexps) Since a Pattern has 0-many regular expressions, it becomes difficult to handle the $0-$n variables (how does the user know which regexp matched? (They can have different number of captures). Setting match variables based on type becomes even more complex if the type is an Optional, Variant or Struct type where one nested type is a Pattern type. Should result be captured there as well? What should happen if there are multiple Pattern types being triggered (say for a struct or collection)? (Short answer: this is neither easy to implement nor easy to understand / use). I think the right thing to do is the following: Remove the special handling of RegexpType for =~ operator that sets match data (As a consequence of the above, a String does not match RegexpType, now only regular expressions do) Specify that matching against a type never sets match variables If we want to do more, we can implement a function that is similar to the matches operator, but that returns matched data as an Array. This function could be given more smarts wrt to matching against regexp, RegexpType, PatternType, and string (regexp in string form) than the boolean "is instance of" that is otherwise performed for types. Also, since it is a function, it does not have to return a boolean (which is the specified result of the matches =~ and not matches !~ operators). # Returns Array of match result where index 0 is the entire matched part, and index 1-n are the captured matches match(string_to_match, pattern_or_type) This function has several benefits: Does not rely on the magic $0-$n The match variables $0-$n only work for the simplest cases as they are overwritten by the last match operator to be evaluated. Suggest that this issue is closed with a "Won't fix" in favor of two new tickets "Remove special handling of RegexpType in matches operator evaluation", and "add a match function". Add Comment   Puppet / PUP-957 Case and Selector expressions using Regexp type does not set match vars Since =~ operator treats the Regexp type as if it were a regular _expression_ and sets the match variables, so should the other conditional expressions that invoke pattern matching (case and selector). This is missing in the new evaluator implementation. (Matching is still done, but without the side effect of setting the match variables). This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.