Peter Donald <[EMAIL PROTECTED]> wrote: > At 10:42 27/3/01 +0200, Stefan Bodewig wrote:
>>> * Allow mappers to be genericised so that particular features can >>> * be modified during mapping. >> >>I don't see this as the purpose of a mapper. These attributes (like >>Unix file permissions) are decorations of the plain filesets, >>nothing that has any connection to the mapper concept at all. > > Isn't the concept of a mapper to map one file (or fileset) to > another? Hmm, not the original concept, no. The original was to do file name translations - which doesn't mean we couldn't extend it. I'm not convinced that adding attributes like file owner to a set of file is the same as mapping one fileset to another. >>> * provide support for non-hardwired (ie loadable) converters. >>> >>> Currently we have fixed set that is expanded on occasion (ie >>> includes primitive types + File). Instead of spreading >>> converting code through out tasks it can be centralized into one >>> component and used by engine. >> >>But it isn't spread, it is centralized in IntrospectionHelper - but >>not pluggable. Do we need that much flexibility? People could simply >>implement a String argument constructor for their custom attribute >>types. > > String arguement constructors is one way of doing it. However it > doesn't allow certain things like resolution based on context (ie > getting File relative to basedir). Which IntrospectionHelper does already, but I see your point. > Adding it in doesn't loose anything (IMHO actually makes code > easier/simpler) so I can't see a reason to exclude the > possibility. I take that as refactoring IntrospectionHelper to replace the rather lengthy if/else if ... block in createAttributeSetter with polymorphism - and make that user-extendable, right? I'm not all opposed to that, I still question whether one needs that much flexibility, but I agree the cost wouldn't be that big. Stefan
