On Monday 17 February 2003 23:12, Matt Tucker wrote: > Tatu, > > > The only suggestion I have is to encapsulate this workaround > > in one place, perhaps to a utility class file (util/FileUtil.java?), and > > only called from the other place(s) (right now that would be just one > > place?). > > > This way workaround code wouldn't add code clutter to actual > > functionality, and could > > be properly commented in utility class itself. > > Personally, this seems like overkill to me. There is only a single use of > File.renameTo in the entire Lucene codebase, so why not keep the workaround
Matter of taste, I guess... and also depends on whether this is ever likely to be done from any other place, ever. I usually move things like this to a separate class second time I need them. :-) But that's easier if I'm only person working on certain piece of functionality. Perhaps suggestion would make more sense if I had said that the whole "delete old file, rename another file to take its place" operation should be refactored out, as it seems to be 'atomic' operation indexer uses. > code local to that usage? Additionally, we're only talking about a few > lines of code. Is it really better to add a whole new class? At this point it'd be a whole new class, but other self-contained file operations could easily be moved there as well. Anyway, it was just a suggestion, so feel free to ignore it if you think it doesn't make sense. -+ Tatu +- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
