Jose Alberto Fernandez wrote: > Peter, > > this is exactly my point. For every new thingy that we add we now need to > go and modify IntrospectionHelper or something to make special allowances > for it. > > It is bloating the core like mad and in my opinion it is crazy. We need a > unified way to treat this things no matter what the things are. Ant's > engine core should not need to know anything about anything.
Fine - but do this in core, not in antlib. Antlib needs to load whatever ant supports. Not to define new things. I don't have any problem with polymorphism ( or roles ). Nobody said they shouldn't be added. My only comment is that the implementation of polymorphism shouldn't be tied with antlib, and I would preffer a solution that would simplify the core - i.e. interfaces or something like that, that would allow us to treat all components as components at the low level. An unified way to treat all the sub-types should be defined and implemented as part of the core. We can wait with antlib ( the part that loads whatever-things-ant-supports) until polymorphism is defined, but I would preffer having antlib included in ant sooner. Costin > > In an ideal world, we should have an engine core with no reference to any > task/type or its implementing classes and a core-antlib which provides the > classes and definintions for all the > task/types/conditions/selectors/mappers that define core java. > > We could even have separate release cycles for it. > > THAT is the potential for antlib (and it is not polimorphish). > > Jose Alberto > >> -----Original Message----- >> From: peter reilly [mailto:[EMAIL PROTECTED] >> Sent: 25 April 2003 10:30 >> To: Ant Developers List >> Subject: Re: antlib >> >> >> On Friday 25 April 2003 08:31, Stefan Bodewig wrote: >> > On Thu, 24 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: >> > > Look - adding "roles" concept to ant, and adding antlib are 2 >> > > separate issues. >> +1 >> > >> > I tend to agree - that's why I proposed to get antlib into the main >> > trunk with support for types and tasks only. At least for starters. >> > >> > If you want a custom mapper you can do so right now with a data type >> > and refid. The same is not true for filter readers, conditions or >> > selectors. But I feel that enabling that would inevitably >> lead us to >> >> Not quite true for filter readers. >> >> In CVS HEAD, FilterChain has a currently (deliberate) >> undocumented feature of >> implementing DynamicConfigurator. The implementation looks up the >> name in the types and if present and if the bean implements >> ChainableReader >> it is used as a ChainableReader. >> >> This is used to support ScriptFilter. Script reader is an optional >> ChainableReader which depends on the presence of BSF and thus cannot >> be implemented in the same way as the other built-in ChainableReaders. >> >> > the more general polymorphism discussion and this is what I >> wanted to >> > avoid 8-). >> >> I have implemented a generalization of FilterChain's >> usage of DynamicConfigurator in IntrospectionHelper. >> This extends the introspection support to include methods of the form: >> >> public void dynamicElement(<type> name); >> >> So in my local ant build the relavant part of FilterChain.java is >> >> public void dynamicElement(ChainableReader reader) { >> filterReaders.addElement(reader); >> } >> >> and of ConditionBase.java >> >> public void dynamicElement(Condition condition) { >> conditions.addElement(condition); >> } >> >> -------------------------------------------------------- >> >> As regards using roles: >> (note: Roles in the antlib proposal are not completely implemented,ie. >> there is no condition, mapper or filter implementation so >> my comments may be correct). >> >> Roles in the proposal provide three features: >> >> 1) they provide a way of limiting the scope of the tag. I assume that >> this is meant to be used by introspection in the same way as >> the dynamicElement method above. >> 2) As a consequence of 1), the same identifier by be used to >> point to different classes. >> 3) they provide an optional adaptor to allow classes that do >> not support >> a requred interface. >> >> These features may be implemented in different ways, for example: >> >> typedef could be extended to have an implements attribute: >> >> <typedef name="and" classname="o.a.t.ant.taskdefs.conditions.And" >> implements="o.a.t.ant.taskdefs.conditions.Condition"/> >> >> "and" may then only be used in beans that have the method: >> public void dynamicElement(Condition condition) >> >> if the class did not implement the condition, a proxy class >> could be defined: >> <typedef name="diskfull" classname="acme.disk.DiskFull" >> implements="o.a.t.ant.taskdefs.conditions.Condition" >> proxy="acme.ant.ConditionAdaptor"/> >> >> or one could have a class that defines adaptors: >> a new task may define adaptors: >> >> <adaptor classname="o.a.t.ant.taskdefs.conditions.Condition" >> proxy="acme.ant.ConditionAdaptor"/> >> >> -------------------------------------------------------- >> >> My feeling is that roles are not needed to support dynamic conditions, >> filters ..., >> in fact I do not think that typedef is needed: >> >> <loadclasses classpathref="${acme.ant.jars}"/> >> >> <condition property="disk.danger.level"> >> <acme.disk.DiskFull percent="70" filesystem="/tmp"/> >> </condition> >> >> I see typedef/taskdef as providing alaises for java beans. >> >> Peter. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >>
