I like Jons bicycle shed, it has a nice color...

Cheers,
Joern.

On 20.01.2011, at 15:54, Jon Cox wrote:

> 
> 
>  Here's how I'd paint the shed:
> 
> 
> 
>    First style:   basic
>    Second style:  derived
>    Third style:   plugin-provided
> 
>         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
> 
> 


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to