> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 30 January 2002 6:29 PM > To: Ant Developers List > Subject: Re: [myrmidon] add TaskContext.getService() > > > Hi, > > On Sat, 26 Jan 2002 17:14, Adam Murdoch wrote: > > > I tend to think of services as different from types. Services > > > persist over > > > the length of the ant "execution" or at least the "workspace > > > execution" or > > > whatever term we were using for this. Types are created by tasks while > > > serviuces never can be etc. > > > > Exactly. And that's why they would use different roles, to distinguish > > between what they are and how they should be used. But that > doesn't mean > > the same infrastructure shouldn't be available to both services and > > data-types. > > I think we mean different things when we are talking about > services vs types. > When I think of services I tend to think that the services are a > semi-singleton available throughout the execution of all tasks. > Where types > are created and used as needed. >
No, we're talking about the same thing. I just wasn't being terribly clear. What I meant was that we should try to use a single general-purpose mechanism for creating instances of services and data-types (and all the other things that come from typelibs - tasks, project builders, converters, whatever). Exactly when instances can be created, and how they are used, is going to be different for each role. So, for example, allowing a service implementor to specify a factory, rather than the implementation class, is a useful thing. But there's nothing special about services in that respect - no reason why a task implementor shouldn't be able provide a factory for the task. Same goes for the inline configuration in the descriptor, or specifying a default implementation. All generally useful stuff. We can make TypeManager responsible for the instantiation of everything that comes from a typelib (and it more-or-less is - it just doesn't do services yet). Then, we add to TypeManager the things we might need for services, such as the ability to *optionally* provide a factory, the ability to *optionally* specify a default implementation for a role, that kind of thing. Again, it would be handy to have a role hierarchy. Thinking about it, 2 levels would be enough. At the top level would be the generic roles, such as DataType, Task, Converter, Service, ProjectBuilder, that kind of stuff. Underneath each of those would be the custom roles, such as Mapper or Condition under DataType, or JavaCompiler under Service. > For instance - consider the Javac task. It would use the JavacExecManager > service. Depending on parameters passed in the JavacExecManager > would use a > JavaCompilerAdaptor object (ie Jikes, Modern, GCJ whatever). > > So in this case the task does not directly interact with the > GCJ/Jikes/etc > types but instead acts through the service which would in turn > use the types. > Thoughts? > > -- > Cheers, > > Pete > > *------------------------------------------------------* > | Hlade's Law: If you have a difficult task, give it | > | to a lazy person -- they will find an easier | > | way to do it. | > *------------------------------------------------------* > > -- > 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]>
