>> am I totally wrong that I'd like to use 'handles' like this? > Hmm, no not really, this is kinda nice.
My initial impression is, if this would be a pragmatic solution to a minor problem. I've never needed or wanted to do this. However, there was an objection into making `predicate => 1` generate to the "has_$_" convention, and there was objections to having sprintf rules in the attr declaration because all of this made the accessors more complex by giving it smart behaviors to alternate and otherwise useless input. I'll take a guess at these questions with what I would expect from such an interface (having never seen the syntax before, you can use my answers for testing least-surprise: > - Would you expect this work with Native traits? If so how would you expect > it to work? I would expect a fatal error, native only accepts a hash ref, he uses it in an > - What is the order of evaluation? Is that even relevant? What might be some > issues that would bring up? I would expect the order not to be relevant, because a regex is a fundamentally different data-type from a string. Making it only work as the last method would require more information about implementation rather than just thinking this is what a regex does in this context. > - Would you support having multiple regexprs in the list? Again how would > order of evaluation be handled? What if it matches for one regexpr and not > for another? Is this a conflict? or do we accept both? Accept both. > - How do you handle methods which match the strings and also match the > regexpr? Is the method list made unique before applying? Same for multiple > regexprs? I would expect the possible method list for importing to be reduced and accumulated for the application with each string/regex match and to be naturally unique. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
