On 18 March 2013 08:17, Luke Daley <[email protected]> wrote: > > > On 17/03/2013, at 15:38, Adam Murdoch <[email protected]> wrote: > > Hi, > > It seems we have some inconsistency in the APIs for adding things to > containers. There are 2 basic operations that the containers offer: > > 1. Adding something that has already been created to the container. > 2. Creating and adding something to the container as a single operation. > There are a few variations on this - create and add if not present, create > and add and configure, create a thing with this name, create a thing with > this name and type, and so on. > > For #1, we always use Collection.add(T), so this is fine. > > For #2, sometimes we call this 'add' and sometimes we call this 'create': > - NamedDomainObjectContainer defines create(name) and most containers just > inherit this. > - ConfigurationContainer defines add(name) and also inherits create(name). > - (the old) SourceSetContainer defines add(name) and also inherits > create(name). > - TaskContainer defines add(name) and add(name, type) and also inherits > create(name). > - PolymorphicDomainObjectContainer defines create(name, type) methods and > inherits create(name). Most polymorphic containers just inherit this. > > Given this, it probably makes sense to deprecate the add(name) and > add(name, type) methods and use 'create' as the term for this operation. > > > Makes sense to me. > > +1. It's a bit confusing as it is now.
-- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
