This approach would be sufficient for my needs...
OK, so let's keep things the way they are for now.
2. If there's some reason that the current approach wouldn't be OK, then I would propose that we embed the "or" into the FilePattern string itself: ActiveTime("**/*.c, **/*.h, **/*.cc")
I think Cedric mentioned that the comma token poses a conflict when parsing certain functions containing a file pattern and email, e.g. ActiveTime("**/*.c*", "[EMAIL PROTECTED]")
You didn't parse my example correctly. :-)
If I am not mistaken, the first argument to the ActiveTime reduction function is a string that is passed to FilePattern.
So, ActiveTime("**") results in a call to FilePattern("**").I was proposing the extend the set of admissable strings that can be passed to FilePattern to include comma-separated patterns.
So, ActiveTime("**/*.c, **/*.h") results in a call to FilePattern("**/*.c, **/*.h"). Note that there's still just one string argument.
In this approach, there's still no ambiguity, and you can easily define a second ActiveTime reduction function constructor that accepts a string containing an email address as a second argument:
ActiveTime("**/*.c, **/*.h", "[EMAIL PROTECTED]")If the time comes that we actually have a need for logical operators in FilePattern specifications, I am certainly open to discussion regarding whether or not a comma-separated list indicating an implicit OR is the right syntax.
Cheers, Philip
