On 20/01/2011, at 7:40 AM, Hans Dockter wrote: > > On Wed, Jan 19, 2011 at 8:56 PM, Peter Niederwieser <[email protected]> > wrote: > > Dump of my brainstorming session: > > First style: untyped, general-purpose, free-form, ad-hoc > Second style: typed, special-purpose, specialized > Third style: predefined, standard, default, implicit, plugin-provided > > I'm not sure whether I like the term untyped. In the courses I make a strong > point that all tasks have a type and thus an API. And that tasks where you > don't specify the type have a default type.
They are untyped in the sense that the build language says nothing about them. The build language 'compiler' - ie Gradle - cannot infer anything about them. The typed tasks, on the other hand, allow Gradle to statically infer a bunch of stuff about them. For example, it know the configuration properties available for the task, and so can validate them early in the build, auto-wire the dependencies, do content completion, and so on. Over time this set of inferable stuff will grow. Perhaps 'statically typed' vs 'dynamically typed' is another option. Or 'declarative' vs 'imperative'. Or 'modelled' vs 'unmodelled'. > Typed task do not need necessarily be special purpose. People might > introduce a non-default general purpose task type with a property let's say > called timer. > > I think the big difference is whether task types have a default action or > not. This is what makes them special purpose or general purpose. I like the > terminology special vs general purpose. This doesn't work for me. I think these terms better describe the different styles of task types, ie the java Class for a given task instance. Some task classes are general purpose and some task classes are special purpose. These terms don't work when you talk about the task instances. Untyped tasks are almost always used to define a task which performs some very specific piece of work for a single build. In this sense, the task instance is a special purpose task. But untyped tasks are also used for general purpose, abstract tasks as well, such as 'check', 'assemble', or 'build'. So, perhaps we skip this question entirely, and instead change the documentation to focus on the task classes. This way, all task instances are typed, and task classes can be special or general purpose. And standard or custom. > > For the third type I like the term standard tasks. It expresses the fact that > plugins can standardize the build for a certain domain aspect. It makes it > clearer to people that Gradle is also about standardization. 'standard' is good. -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
