In message <[EMAIL PROTECTED]>, steve cohen writes: >Oops! CVS doesn't have "undelete", does it? :-( Sorry for not >knowing/understanding this rule. Do we add it back in (losing history) or is >there some way to put that back as well? What is best way to proceed?
It looks like you already took care of it. But it should extend FTPFileEntryParserImpl so we don't have duplicate code. I don't know if you're still making changes, so I don't want to mess with anything. >But I think these names confused you. At least that's the way it looked to >me. The iteration that was needed was over the Vector of raw input in >FTPFileList. When I saw you specializing FTPFileIterator, which walks raw >input but returns "cooked" equivalents, I knew you had gone down a wrong No, I just didn't explain myself clearly enough. I was concentrating on teasing out the interfaces. The implementation didn't matter as long as the proper behavior was preserved. That's why I just shuffled code around without actually reimplementing any of it. A subsequent step would be to optimize the specialized iterator so it would incrementally work off of the raw input lines. However, the approach would be through subclassing and making some members of what I called DefaultFTPFileList protected instead of package scoped or private. I still think the changes you made are too application-specific. FTPFileList preParse(FTPFileList) is entirely motivated by the VMS problem and I don't see it holding up to software evolution demands. The need to continue exposing implementation details through methods like getInternalIteratorForFtpFileList (should be getInternalIteratorForFTPFileList to maintain consistent naming) is evidence of an architectural flaw. If we continue to violate data encapsulation, favoring customization through exposure of private data instead of through inheritance, we're going to make the software more difficult to maintain. >path. I'm not against abstracting some of these classes. It's probably a >good idea and once we have it, further beneficial refactorings will no doubt >suggest themselves, but I think that is for 2.0. I disagree. I think the time to fix this is now. Otherwise, we're just adding more methods that we're going to have to deprecate. That said, this affects us more right now than it affects users. It's not like there's a huge amount of user code dependent on the list parsing classes. Most users use what we already provide. Anyway, I know I still haven't expressed myself as clearly as I could (time constraints), but I'd like to fix up my suggested changes to something closer to what I'm ultimately trying to propose in order to make it more clear. Rather than work on what's in CVS, I'll just post the changes for download later this week after I free up some time. Some things are just more clear when looking at examples. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
