From ant-dev-return-12123-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org Tue Mar 27 21:16:13 2001 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org Received: (qmail 98993 invoked by uid 500); 27 Mar 2001 21:16:09 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 98970 invoked from network); 27 Mar 2001 21:16:07 -0000 From: David Rees To: ant-dev@jakarta.apache.org Subject: Re: [DISC] Datatypes Date: Tue, 27 Mar 2001 13:15:19 -0800 Reply-To: d.rees.l@usa.net Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On 27 Mar 2001 10:42:06 +0200, Stefan Bodewig wrote: >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. > >If this is only a means to get the decoration connected with the >fileset, I'd prefer a different syntax. > I agree that mappers are used for filename mapping, not file modification. Actually, mappers should be used for path modification. I make the distinction because they should be applicable to a variety of sources (file system, ftp, http, zip, etc.). =46ile modification should be handled by a task acting on a set. >> * Allow include/exclude tow work with multiple characteristerics of >> * a file. > >Generally +1, need to look into David's Culler proposal. But we need >to provide a simplified syntax for the common case of file name >matching. > I agree. The question is if we should really support merging a certain default nested element into its parent (like FileSet in Javac). So becomes: Or possibly somewhere in between. Or, if we like my idea of merging attributes and nested elements along with "auto-sets": > >>=20 >> * provide support for non-hardwired (ie loadable) converters. >>=20 >> 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. > At the very least it needs to be refactored in IntrospectionHelper so it can be reused outside of it. Perhaps simple static methods would suffice. >> * Make all datatypes interfaces to allow them to be customized in >> * many ways. > >Where appropriate, but not all of them. > Which ones do you not like? >> * Set arithmetic for fileset/patternset/*set > >+1 > >> * inheritance of ant properties/datatypes/context etc in project >> * hierarchy > >comes for free with the unified namespace. > >>=20 >> * inheritance of between ant datatypes. ie fileset A inherits from >> * fileset B (includes all entries in A). > >If "(includes all entries in A)" is the description for inheritance >here, this is covered by set arithmetic. > >> * Homogenize notion of PATHs and filesets. > >Doesn't always make sense, we need the specific use cases where paths >and filesets are interchangeable. > When are they not? d