> -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Thursday, 21 February 2002 1:10 AM > To: [EMAIL PROTECTED] > Subject: Re: antlib descriptor > > > On Wed, 20 Feb 2002, Adam Murdoch <[EMAIL PROTECTED]> wrote: > > > I want to change the Foo.addBar() case to work similar to the way > > Mutant does, with a 'type' attribute. The type attribute would be > > optional. > > [...] > > > Given that myrmidon doesn't actually use roles during configuration, > > In my previous mail I assumed, it did, sorry. > > Maybe it should, instead of using an additional attribute like Mutant? > This could lead to an inflation of roles, though. >
Yes, it is about to start using roles again. Mainly because roles are a handy place to attach meta-info to (e.g. things like the default implementation, or specifying a particular type factory to use). Once that is done, I want to write up how configuration in myrmidon works, so people can get a clearer picture of it (it *does* sound complicated in all these emails, but it really isn't). As far as inflation of roles goes, well, Myrmidon already has dozens of them. There is a role for pretty much everything that is pluggable. And there's a lot of those. > > we should decide how syntax is going to work, and then worry about > > whether roles should be a visible part of the solution. > > If we make roles invisible in the descriptor, we make it impossible > for library providers to define their own pluggable elements in just > that descriptor, don't we? > Well, yes. For now, I think we should leave out the ability for an antlib to define new roles (ie new groups of pluggable elements). Let's stick with 'task' and 'data-type'. Of course, that doesn't mean we won't be using the roles concept internally. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
