From: "Wannheden, Knut" <[EMAIL PROTECTED]> > > From: <[EMAIL PROTECTED]> > > > > I agree in part. I think APIs passing "Object" should be > > avoided as much as posible. > > They say nothing about the constraints imposed by the API. It > > makes no sense to > > pass things other than those able to produce an stream of > > input to the current implementations > > of ProjectHelperImpl. > > > > Why a stream of input? As an example is a DOM tree certainly not a stream, > not has it necessarily been constructed from one, but it is perfectly suited > as input for an Ant project. In this case I think Object as input makes > perfectly sense as it should really be left up to the implementor what kind > of source he'd like to read the input from. But of course he has to know > that he will have to deal with File objects if he uses the <ant> task or the > like. In this case he might just delegate to the standard > ProjectHelperImpl. >
I think the best analogy here is the way the JDOM API works. JDOM provides the concept of a JDOMFactory interface whose implementations are the ones actually constructing the model (I would argue this is the equivalent to what we want ProjectHelper to be), and then you have several *Builder classes that direct the construction of the model from diferent sources (DOMBuilder, SAXBuilder, etc.). In such a model there is no need to pass "Object" parameters around, things are well typed and the compiler can do its proper job. > But I agree the default ProjectHelperImpl provided by Ant should probably be > able to handle URIs not only Files, but I guess this is the general idea > anyways. > Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
