ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: Need feedback on intended SourceFileScanner change
Date Tue, 03 Dec 2002 16:18:31 GMT
Maybe a higher level abstraction is also in order.

With TargetObject (I will stick to this name just to
move ahead with the discussion) and isDirty, we have 
a mechanism to see if a target object is outdated or 

However, the consumer of this still needs to do
the dirty work of having to iterate through all 
the Source Objects and see if the corresponding
target Object needs to be updated.

Instead, if we have something like an UpdateManager
that has a setter for the Source Objects and a getter 
for the Target Objects, it would be very useful also.

interface UpdateManager {
    void setSrcList(List src);
    List getDestList();

An implementation of UpdateManager's getDestList 
method would iterate through each src element and 
invoke TargetObject's isDirty using it and build 
the dest list with just those src elements that 
need to be updated.


----- Original Message ----- 
From: "Stefan Bodewig" <>

> Thanks for your comments, Magesh and Dominique.
> On Mon, 2 Dec 2002, Dominique Devienne <> wrote:
> > From: Magesh Umasankar [] 
> >> public boolean isDirtyWhenComparedWith(Object src);
> >> or if the "WhenComparedWith" seems to be pedantic, 
> >> public boolean isDirty(Object src); 
> >>
> >> Other implementations of TargetObject may choose 
> >> different mechanisms to perform the comparison before 
> >> saying that the target object is dirty or not.
> > 
> > I like this abstraction. But would it work with a mapper that
> > returned several files to check dirty status given the proposed
> > single object signtature?
> As it is right now, TargetObject would be what the mapper has mapped
> to, so it would work (you have a single source file and multiple
> TargetObjects).
> >> As far as naming goes, the Object part in TargetObject seems
> >> pedantic to me.
> What do you expect, it's me 8-)
> > I don't like that name personally. TargetObject seems designed
> > exclusively for SourceFileScanner, and thus should relate to it by
> > name.  Something like SourceFileItem?
> Which could be applied at both sides (taking the abstraction to the
> source side as well), yes.  But if I wanted to move it to the source
> side as well, I'll soon get into trouble with isDirty as FileItem
> would need to know how to compare itself to a ZipItem or something.
> Stefan
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message