anchor.diff:  --
   
   Note that accessors for elements of containers such as `configurations`, `tasks` or `sourceSets` leverage Gradle's configuration avoidance APIs.
  -For example on `tasks` they are of type `TaskProvider<T>` and provide a lazy reference and lazy configuration of the underlying task.
  +For example, on `tasks` they are of type `TaskProvider<T>` and provide a lazy reference and lazy configuration of the underlying task.
   
   [source,kotlin]
   ----
  
positive.code: 
  In IntelliJ IDEA, you must link:https://www.jetbrains.com/help/idea/gradle.html#gradle_import[import your project from the Gradle model] to get content-assist and refactoring tools for Kotlin DSL scripts.
  
  In addition, IntelliJ IDEA or Android Studio might spawns up to 3 Gradle daemons when editing scripts; one per each type of script: project scripts, settings scripts and initialization scripts.
  Builds with slow configuration time might affect the IDE responsiveness, please check out the link:https://guides.gradle.org/performance/#configuration[performance guide].
  
  === Automatic build import vs. automatic reload of script dependencies
  
negative.code: Note that if you are configuring existing elements on supported containers you can leverage the type-safe accessors as described in the <<sec:configuring_plugins>> section above.
  --
  
  The Gradle Kotlin DSL provides build authors with uniform ways of interacting with containers.
  We already saw some examples configuring source sets or tasks in the <<sec:configuring_plugins>> section above.
  Let's now look in detail at how to interact with containers using the Gradle Kotlin DSL by using the `tasks` container as an example.
  
  === Using the containers API
  
  All the containers implement `NamedDomainObjectContainer<DomainObjectType>`, some of them can contain objects of different types and implement `PolymorphicDomainObjectContainer<BaseType>`. The first and simplest way to interact with containers is through their API.
  
  .Using the containers API
  ====
  