CommonTaskProperties vs SettingsClass.BaseClass

[kkopanski]

What I can see is that we have two methods of adding common properties to tasks:

1. commonTaskProperties which will add listed properties in most derived settings class (this one generated for specific task).
2. Specifying some custom class in dataTypes and putting it in settingsClass.baseClass in task definition.

I would like to get the idea behind commonTaskProperties in tool definition json, as I can't see any advantages for it:

• There will be many occurrences of those properties, thus code duplication.
• It is not possible to create custom extension methods manipulating those properties, as you must work on most derived type.

So if is better to move all commonTaskProperties to base settings class or am I missing something?

[kkopanski]

Using PR #1235 as an example it allows writing extension methods like this:

public static T ConfigureCommonProperties<T>(this T settings)
    where T : UnityBaseSettings
{
    return settings
        .SetUsername("user")
        .SetPassword("pass");
}

and use it like this:

UnityTasks.Unity(_ => _
    .ConfigureCommonProperties()
    .SetProjectPath(RootDirectory));

instead of writing SetUsername and SetPassword in every invocation or writing many extension method per Task.

[kkopanski]

Just found that there is actually some advantage of using commonTaskProperties...
Those parameters are added in XML comment remarks section.

Looks like a missing feature in tool generator?

[matkoch]

Honestly I can't remember if there's any advantage of one over the other. Code generation in general could deserve a complete rewrite.

[kkopanski]

Well... that's also an answer.
If we find that using base class better suits us - we should use it.