commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From steve cohen <sco...@javactivity.org>
Subject Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Date Fri, 09 Jan 2004 12:46:41 GMT
On Friday 09 January 2004 03:22 am, Daniel F. Savarese wrote:
> In message <200401071338.27953.scohen@javactivity.org>, steve cohen writes:
> >I also agree that there is a need for postfiltering (to solve the "most
> > recent version only" problem), although, actually, I think prefiltering
> > out the dupes may be the way to go.  Either way, some kind of hook will
> > be necessary, one that's a no-op in the default case.  If time gets to be
> > a factor we can leave this as a known issue for later.  No one's actually
> > complained about it other than me, from reading the code.
>
> I went ahead and made the changes I had put out for discussion (see
> comments in CVS commit log).  It seemed easier to make them and let you
> improve on them or revert them.  There should be no impact on existing
> code. However, I had to introduce createFTPFileList into the
> FTPFileEntryParser interface.  I don't like the name of this method.  It's
> basically an FTPFileList version of parserFileList.  If we keep this
> change, we should ome up with a more appropriate name.

I'll take a look at it.

>
> There are some things I didn't understand in FTPFileListIterator (now
> an abstract class with DefaultFTPFileListIterator containing the
> implementation code).  Is getNext(0) supposed to return all remaining
> elements and getPrevious(0) all elements between 0 and the current
> position?  

Yes.  I had to look at the code but that's what the code does and the javadocs 
indicate the same.

> Also, FTPFileList.getFiles() (now DefaultFTPFileList.getFiles()
> with FTPFileList being an abstract class) was returning
> iterator().getNext(0). I changed this to iterator().getFiles(), which was
> less confusing to me. But it seems that getFiles() actually does something
> different than getNext(0), reinitializing the current position.  Is there
> something that needs to be fixed there?  I didn't want to change anything
> there.

Good catch.  This was a flaw and you fixed it.  getFiles() gets the complete 
list.  getNext(0) gets the rest, which is the same only if done from the 
beginning.

> Please doublecheck VMSFTPEntryParser.DuplicateFilteringIterator to
> ensure it implements the getNext() and getPrevious() methods as
> intended.  I included little comments saying how I interpreted the 0
> argument.
>
> I didn't fix up all affected javadocs (too late, too tired).  I also
> didn't split out VMSFTPEntryParser into two classes, but that should
> be easy for anyone else to do.  Basically, all I did was shuffle code
> around to make user customization easier.  The only new code I wrote
> were a couple of methods in DuplicateFilteringIterator, but it really
> just grafts part of the old parseFileList which is now split between
> DuplicateFilteringIterator and createFTPFileList().

I'll take it from here.  I should be in good shape by the end of the weekend.  
I'm putting a new computer system together today.


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


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


Mime
View raw message