ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: svn commit: r714053 - /ant/core/trunk/src/main/org/apache/tools/ant/types/resources/
Date Mon, 17 Nov 2008 11:06:26 GMT
Stefan Bodewig a écrit :
> On 2008-11-14, Nicolas Lalevée <> wrote:
>> I am not sure of how are used the "Resource" in the Ant code, but it
>> makes me think of the Eclipse adapters (probably a design pattern ?):
> Sounds reasonable.
>> Though it changes the tests of the appendability, the touchability,
>> etc... of a Resource in the ant code, the "instanceof+cast" would be
>> replaced by some "getAdapter". This solution is not very self-
>> contained...
> Yes.  I may stick a single subclass for FileProvider resources and
> modify all occurances of Appendable and Touchable to use the adapter
> method.
>> But I see another solution, quite different. Probably most of the work
>> should be done in the Resource class:
> I thought about that, but Resource is already doing way too much IMHO.
Well, in fact here you want a functionality to Resource (AFAIU). And it 
makes me think of the multi-inheritance issue. And after a long debate 
with a colleague of mine, he convinced me that multi-inheritance can 
always be resolved with single-inheritance + composition: extract the 
functionality into its own class and make it a composition of the main 
class. Even more, since I understood it, my code began very modular 
actually, even if it began to be composed of a lot of handler.handle().

If you choose the former solution, then each time you want to add 
another implementation of Resource with some new capability, you will 
have to support it in MappedResource. By the way, what about the 
Resource implementation in some ant plugins ? Is the Resource API 
exported ? Wouldn't the former solution break some ant plugin ?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message