On Fri, 26 Jul 2002, Wannheden, Knut wrote: > well the thing about backward compatibility... as File is a subclass of > Object, I guess that the parameter could be changed and a explicit downcast > (where needed) would do. But if performance is a concern a new method would > probably be better.
Not performance - the method signature must match otherwise you need to recompile. > But otherwise sounds good! This will make a cleaner interface for people > writing custom frontends as they can supply their own ProjectHelper and > practically call it with any input. Just the ProjectHelper knows how to > deal with it ;-) I think you are talking about frontents supplying their ProjectHelper implementations, not replace oat.ant.ProjectHelper. That's how it think it should work. Costin > > Cheers, > > -- > knut > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Freitag, 26. Juli 2002 19:01 > > To: Ant Developers List > > Subject: RE: Embed Sandbox Proposal: HOWTO? > > > > > > On Fri, 26 Jul 2002, Wannheden, Knut wrote: > > > > > >From your description it is not quite clear to me if your > > new ProjectHelper > > > is intended as a plugin for the oat.ant.ProjectHelper or as > > a additional > > > implementation of a ProjectHelper like > > oat.ant.helper.ProjectHelperImpl. Or > > > have you maybe even done both? > > > > It is a pluging for oat.ant.ProjectHelper, replacing the default > > ProjectHelperImpl. > > > > ProjectHelper is the 'interface' ( well, base class ), > > ProjectHelperImpl > > is one implementation ( the default one ), PHI2 is an alternative one > > ( and I hope default for next release ). > > > > > > > If you're working on the oat.ant.ProjectHelper I have a > > small change to > > > propose: The parse(Project, Object) method allows a > > ProjectHelper plugin to > > > set up a Project from an arbitrary input, not just a File. > > But the method > > > is actually called from > > oat.ant.ProjectHelper.configureProject(Project, > > > File), which is the actual entry point. And this makes it > > impossible to > > > read from anything other than File. So if the File argument of > > > configureProject() were changed into a Object argument, the > > problem would be > > > solved. > > > > I don't think we can change the File argument ( backward > > compat :-), but > > we can add a second configureProject with Object param ( that would be > > backward compatible, and since it's abstract class not > > inteface we could > > still compile for both ). > > > > Seem like a good idea. > > > > I'm not sure what's the right procedure - since it's an API change to > > a core ant class it may be a good idea to make a formal proposal. > > But it's a pretty small change - so I can check it in and > > wait for -1s. > > > > Costin > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
