https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
Jesse Glick <jgl...@netbeans.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jgl...@netbeans.org --- Comment #1 from Jesse Glick <jgl...@netbeans.org> 2012-03-05 20:42:14 UTC --- Such types should indeed implement Iterable. The question is what the type parameter should be. In the case of ResourceCollection, probably the parameter should be Resource. Now if this were actually "? extends Resource" then FileSet could override this to be an Iterable<FileResource>, or ResourceCollection could even itself take a type parameter describing the subtype of Resource it contains, but I am not sure we want to get this complicated with generics - it can be rather tricky to understand such code and make it work correctly with extensions. Probably simpler and better would be to leverage the Resource.as method and do not allow covariant Resource subtypes. Then FileResource can continue to be an implementation detail, which FileSet and friends would not be obliged to use, and your client code would do something like: for (Resource r : someFileSetOrOtherResourceCollection) { File f = r.as(FileProvider.class).getFile(); // ... } which extends naturally to other extension interfaces like URLProvider. I believe this works in Rhino JavaScript as well (just omit the ".class" on the type token and of course qualify it if needed). Of course if you are unsure what the collection might consist of, you must check each call to as(FileProvider) for a null return value. There could also be convenience methods somewhere (Resource? Resources? Files?) such as /** call {@link Resource#as} on each element, throw NPE or similar if missing */ public static <P> Iterable<P> as(ResourceCollection rc, Class<P> type); /** obtains {@link FileProvider} from each element; must be filesystemOnly */ public static Iterable<File> asFiles(ResourceCollection rc); to simplify loops. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.