At 09:47 PM 6/6/01 -0700, James Bucanek wrote: >>>On occasion, I've been writing my own mappers to preform filtering as >>>a side effect, but it's pretty ugly. Especially since you can't >>>extend the mapper tag to include any additional information that a >>>filter might need to do it's job. >> >>right - I wanted to extend mappers to do this sort of thing but it was >>-1'ed ;) > >Well I suppose it depends on how you did it, but I'd probably would >have -1'd it too. :( > >I think filters (aka "cullers") perform a separate function from >mappers. For one, you'd have the flexibility of being able to >specify cullers and mappers in arbitrary combinations. And, cullers >would could apply to single (source file list) task contexts whereas >mappers logically imply a target file for each source file.
I am not sure I agree. In my mind mappers, map an attribute of input item to an attribute of output item(s). Currently we restrict that to just one attribute (name) but "culler" functionality is a generalization to multiple attributes (read-access, modify-time, etc). BTW currently mappers can map many-to-1 and 1-to-many (or none) so I am not sure "mappers logically imply a target file for each source file" is completely accurate ;) It would be more accurate to say "mappers logically imply zero or more target names for each input name". Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
