Here's how I'd paint the shed:
First style: basic
--------------------
Rationale: This implies "no special magic here",
which is exactly what is meant.
It also hints that other kinds of
tasks exist that are fancier,
which is true (i.e.: "derived").
Second style: derived
-----------------------
Rationale: This implies that some customization was
performed, such as magical default behavior.
It also nicely compliments the term "basic".
Third style: plugin-provided
------------------------------
Rationale: The salient quality is that it was provided by
a plugin, so it really is the most accurate and
non-opaque term for both someone learning the
system and experts.
The term "standard" presents a nasty problem:
If someone uses a non-standard/custom plugin,
would you then need to start calling things
"non-standard standard task" ... or
"custom standard tasks"? That's painful.
The term "predefined" isn't awful, but it fails
to be specific about what "pre" means. By contrast,
when you mention the word "plugin", you know just
where to look.
The term "default" is also kind of lame because
lots of stuff can be defaulted via customization;
the point is that the task comes from a plugin...
so just say so! The term "implicit" has the same
basic problem. Effectively, every indirect action
is "implicit" in a meaningful sense of the word.
Note: saying a task is "plugin-provided" is a stronger
statement than saying that it was "derived"
or "basic". The terms combine well too:
"this is a plugin-provided {basic|derived} task".
Cheers,
-Jon
* John Murph ([email protected]) [110119 14:02]:
> On Wed, Jan 19, 2011 at 3:40 PM, Hans Dockter <[email protected]> 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. 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.
> >
> > 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.
> >
> > Cheers
> >
> > Hans
> >
> >
> Hey, bicycle shed colors, I can argue about this! (This comment references
> the idea that everyone is willing to argue about bicycle shed colors,
> because it doesn't really matter so there is no right or wrong answer.)
>
> Maybe the first style could be called "ad-hoc" tasks and the second style
> "customized template" tasks (I suggest "template task" as a simpler form).
> I guess the idea of special vs. general purpose would make these types seem
> opposite, when they are really orthogonal issues. What might we call this
> task:
>
> task myTask(type: SomeType) {
> someProp = 'value'
> }
> myTask.doLast { some more stuff }
>
> Is this a general purpose task with specialized parts? Or a template task
> with ad-hoc additions? Or a bad idea (although I've done this)? :)
>
> I agree with Hans for the third type, however. I like "standard" tasks.
>
> --
> John Murph
> Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
