I'm not sure that separating include/exclude rules from the remapping is a
good idea. On the surface it sure sounds reasonable, but I think it would
make our use case much uglier. Our remap code is sorta like:
remapTarget { File inputFile ->
if (not a special file)
return inputFile
perform phase one renaming // fairly complicated
perform phase two renaming // also complicated
if (resultName is not valid) // did phase one and phase two result in the
desired format?
return null
else
return resultName
}
The point is that phase one and phase two renaming are not simple replaceAll
kinds of functions. This means that if we were to split up these concepts
we would has an include/exclude closure that performed the logic and then
checks if the resultName is valid. Then we need a mapTo closure that
performed the logic and returned the result (with an assert failure if the
result name is not valid?). Now, we could pull this common stuff into a
method, but it just seems an overly complicated way of getting the desired
behavior. It also seems like it would affect performance when processing
over 30,000 files.
--
John Murph
Automated Logic Research Team
