> > I agree in general that what is there is goofy/wrong, but I'm not sold > > that this is an adequate fix. > > > > I'm not sure either. That's why I sent it to the list :) > > > > The thing is that opaque strings *are* different to IP addresses or > > hostnames, which are being decomposed into their components > > precisely so that we can have partial matching on some components. > > > > This simply isn't possible with an opaque string.
Sure it is. I'd propose "decomposing" the opaque string into an array in exactly the same way; such an array would typically contain a single string or (should the opaque string contain periods) a series of strings corresponding to the segments of the "." delimited segments of the opaque string. In either case, such an array would compare the same way the original string would have. > > Although I'm not convinced, I can see some merit in demanding that > > pattern is always an array, so I see these options: > > > > a) ... The easiest option is to just stop special casing opaque strings in matchname?() and we're done. > > I still really don't see any reason why matchname? needs to call > > munge_name on non-opaque values given that they've all already run > > through it already .... Ah. It's not, or rather, they haven't. It's calling it on the concrete values to be matched against the already processed patterns. Not clear from the source though, is it? > An overall refactor has been mentioned multiple times, but what would > that refactor look like? 1: Get rid of all the "you set it as an String but get it as an Array (reversed even)" mumbo-jumbo. 2: Separate the three sets of concerns (pattern validation, patterns application, and pattern specificity sorting) to each interpret/deal with the shared data as needed for their purposes without mutilating the fields in the process. 3 (optional): Have a handful of decedent classes from Puppet::Network:: AuthStore's Declaration class (e.g. IP_declaration, Host_declaration, etc.) and have each one know how to match according to its own rules and sort (<=>) by a shared key-off-of-this convention. Move validation / error checking to a factor method. > It seems to me we just need our matchname? method to be a bit more > state-based - match one way when opaque and another when not. This > could be done pretty easily with a branch to two separate methods, > couldn't it? That seems like an appropriate action to me. Sure, if the goal is to make it more complicated. On the other hand, just removing the partial special casing for opaque strings would do the same thing. -- Markus --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
