Sounds reasonable to me. On Sun, Mar 17, 2013 at 11:38 PM, 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. > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com > > -- Szczepan Faber Principal engineer@gradleware; Lead@mockito Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
