ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Kruithof ...@kruithof.xs4all.nl>
Subject Re: [patch] NioFileUtils, Java6FileUtils, FileUtilsAdapter + factory, build.xml (was Re: AW: Adding a methof to StringUtils)
Date Fri, 21 Apr 2006 07:30:35 GMT
Kev Jackson wrote:

>> 2) If the FileUtilsFactory is called from or implemented in 
>> FileUtils.getFileUtils() / FileUtils.newFileUtils(), every task is 
>> going to benefit.
>>
> I think the implementation I provided does precisely this, or rather 
> it calls from the interface (FileUtilsAdapter) instead of from the 
> implementation.  If you mean that the current FileUtils should 
> delegate to another implementation using the factory that's different.
>
> I think it would be cleaner to gradually transition all the tasks over 
> to an interface (while retaining the FileUtils semi-singleton).  At 
> the point where all the tasks are using FileUtilsAdapter, we can 
> refactor and remove the parts of FileUtils that are exposed correctly 
> in the interface, maintaining bwc that way - the only thing left would 
> be a small stub which contains the static methods - that's my view of 
> how a transition would work anyway.
>
> I think that using FileUtils to delegate/proxy to a real class would 
> be less 'elegant' than using an interface - although I can see the 
> immediate advantages of using the approach you mentioned (all tasks 
> benefit without actually having to change each class over to the 
> interface).


In that case I would like some time to think things over, as to provide 
one face, and to have different implementations for currently different 
parts.
Classes that support copying, things that support permissions, things 
that support path manipulation, without getting a really big number of 
classes.

FileUtils for Java 1.6 on Windows
FileUtils for Java 1.4 on VMS
etc.

I had an idea to turn FileUtils into a Facade that delegates different 
actions to different back-ends.


Thanks for your elaborate reaction.

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


Mime
View raw message