ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 26364] - <pathconvert> should support nested <mapper>s in addition to its <map> element
Date Thu, 29 Jan 2004 15:55:06 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26364>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26364

<pathconvert> should support nested <mapper>s in addition to its <map> element





------- Additional Comments From gudnabrsam@yahoo.com  2004-01-29 15:55 -------
As for the behavior of my version... it works in parallel only... I implemented 
my changes with a new interface (FileMapperContainer) with the idea that 
different behavior could be implemented in a different class.  For example, the 
<map> elements of <pathconvert> are here implemented by FileNameMappers that 
use the exact same conversion code as before; these are nested into another 
custom mapper that tries each until a change is made or returns the String 
unchanged, in order to achieve the existing <map> behavior.

Regarding mapper and containermapper... your implementation is both smaller and 
more complication than mine, so I can see good and bad points about both...

On <pathconvert>:  the main difference I see here is that you allow <map>s to

work on the results returned by the <mapper>.  To me, this seemed unnecessary 
and possibly confusing to use; I figured <map>s would really be obsolete, for 
the most part.  Therefore I made <map>s and <mapper>s mutually incompatible. 

The other difference is that, as mentioned before, I reimplemented <map>s as 
<mapper>s internally... while the method is slightly complex at first glance, I 
did it this way because it yielded a set of code from which <map>s could, at 
some theoretical point in the future, be removed entirely with very little 
effort... rip out three inner classes and a method and you've got a working 
version.  A few more lines would remove all trace.  But this is just theory due 
to BC... :)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message