You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2012/03/05 09:06:43 UTC
DO NOT REPLY [Bug 52829] New: implement Iterable interface in
FileSet and others
https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
Bug #: 52829
Summary: implement Iterable interface in FileSet and others
Product: Ant
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Core
AssignedTo: notifications@ant.apache.org
ReportedBy: jarekczek@poczta.onet.pl
Classification: Unclassified
While script task is able to use the following syntax:
for (f: fs)
it is not possible for custom tasks written in java. Since a switch to Java5
all classes implementing iterator() should be declared as "implements
Iterable". See the relevant java documentation:
http://docs.oracle.com/javase/specs/jls/se5.0/html/statements.html#14.14.2
The idea is on the mailing list:
http://mail-archives.apache.org/mod_mbox/ant-dev/201203.mbox/%3CCAE9L6G3-uLwA2EQV_mbdXtnZs_PYb_UMLB5iEX71N%2BqRb1C86g%40mail.gmail.com%3E
and was accepted by Matt Benson.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52829] implement Iterable interface in FileSet and
others
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
--- Comment #3 from Jesse Glick <jg...@netbeans.org> 2012-03-09 14:54:19 UTC ---
(In reply to comment #2)
> FileSet.iterator() returns Object type.
It returns (raw) Iterable today, the elements of which are in fact guaranteed
to be assignable to Resource. The proposal is to specify it as
Iterable<Resource> now that we can use generics.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52829] implement Iterable interface in FileSet and
others
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
--- Comment #5 from Matt Benson <mb...@apache.org> 2012-03-19 17:29:18 UTC ---
Hi all! Some observations:
1. Jesse's proposal, despite being a workable plan, felt to me at first read
like implementing generics in a "halfway" manner.
2. I haven't done any Ant work to speak of in quite some time and thus my
voice doesn't carry so much weight in the doocracy that is an ASF project,
hence my delayed response here.
3. I did particularly like the concept in Jesse's proposal of keeping things
specified to e.g. FileProvider rather than FileResource.
4. I did some experiments with implementing generics more fully along these
lines, but was ultimately unable to get a working structure in place. I feel
that this is because when we fully Resource-ized Ant back with v1.7 (about 7
years ago now!), we were bound by the fact that Resource was a class rather
than an interface. I think that if ever we implement Ant 2, e.g. FileProvider
would directly extend a Resource interface and e.g. DirSet|FileSet|FileList
would expose FileProvider.
My conclusion, speaking (if I'm not overstating the case) as the committer most
directly responsible for the current state of affairs of Ant's Resource API, is
that for the Ant 1.x codebase, Jesse's proposal works where implementing
generics any more deeply will have more drawbacks than benefits, as he guessed.
This is nobody's fault, but just a "shit happens" situation (shituation?).
For Ant 2, I think we can accomplish "full generics done right," if and when
that time ever comes.
Matt
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52829] implement Iterable interface in FileSet and
others
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
Jesse Glick <jg...@netbeans.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #7 from Jesse Glick <jg...@netbeans.org> 2012-04-16 19:30:40 UTC ---
Committed revision 1326760.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52829] implement Iterable interface in FileSet and
others
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
--- Comment #4 from Stefan Bodewig <bo...@apache.org> 2012-03-18 19:50:21 UTC ---
FWIW, I'd prefer Iterable<Resource> and as(FileProvider.class).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52829] implement Iterable interface in FileSet and
others
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
--- Comment #6 from Jesse Glick <jg...@netbeans.org> 2012-03-26 20:26:43 UTC ---
Ah, I did not even notice that FileProvider is not assignable to Resource.
Even ignoring FileProvider for a moment, my fear about FileSet implements
Iterable<FileResource> was that the generics could become more trouble than
they are worth. The only project I know of which made a real attempt to use
generics like this (where you have two parallel type hierarchies linked in a
"ladder" by type parameters) is Hudson(/Jenkins):
class Job<JobT extends Job<JobT,RunT>,RunT extends Run<JobT,RunT>>
class Run<JobT extends Job<JobT,RunT>,RunT extends Run<JobT,RunT>>
class AbstractProject<P extends AbstractProject<P,R>,R extends
AbstractBuild<P,R>> extends Job<P,R>
class AbstractBuild<P extends AbstractProject<P,R>,R extends
AbstractBuild<P,R>> extends Run<P,R>
...
and in practice the code base (1) is full of unchecked/rawtype warnings no one
has ever figured out how to resolve, (2) sometimes fails to compile using new
versions of javac and/or ecj.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52829] implement Iterable interface in FileSet and
others
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
--- Comment #2 from Jarek Czekalski <ja...@poczta.onet.pl> 2012-03-09 10:24:38 UTC ---
To add some background: FileSet.iterator() returns Object type. So one using
iterator() must do the conversion manually.
To make "for" loops more convenient you suggest that Iterable should return a
specific, more useful type. But it would be inconsistent with iterator(). I
don't mind it, just commenting.
If that's too difficult to choose the ideal Iterable type at the moment, you
could simply implement Iterable<Object>. I guess making a specialized Iterable
in the future would not break any code relying on Iterable<Object>.
Anyway I don't feel competent to make directions in this matter, so I'll switch
to a listening mode from now on.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 52829] implement Iterable interface in FileSet and
others
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52829
Jesse Glick <jg...@netbeans.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jglick@netbeans.org
--- Comment #1 from Jesse Glick <jg...@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.