RFC0001-Mutual-Exclusion-Parameters-and-Properties comments

[SteveL-MSFT]

Use this to track comments for https://github.com/PowerShell/PowerShell-Language-RFC/blob/master/1-Draft/RFC0001-Mutual-Exclusion-Parameters-and-Properties.md

[danlyons-home]

It looks like the link above should instead be the following:
https://github.com/PowerShell/PowerShell-Language-RFC/blob/master/1-Draft/RFC0001-Mutual-Exclusion-Parameters-and-Properties.md

The original link is missing the 1-Draft folder between master and the file.

[SteveL-MSFT]

Fixed, thanks! That link was before we thought it was a good idea to have the folders.

[alexneumann12]

Is it feasible to define both methods and allow the cmdlet author to choose whichever style they prefer? If not then I'd personally pursue the [MutuallyExclusive()] attribute since it's more concrete as to what is being excluded against another.

[WouterDeKort]

My preference is the MutuallyExclusive syntax. When you have a lot of properties it's easier to see them all grouped together then have the ExclusionSet spread over all properties.

I do wonder however how hard it is to set these attributes for a large number of parameters. But that's an issue that we already have today and that's not easily solved with syntax (I think). Having run time validation to make sure that you don't exclude a property from all combinations would be nice.

[MikeShepard]

I feel like both the existing ParameterSet syntax and the MutuallyExclusive syntax hide the intent. Since we're specifying "use cases", could we list the use cases with the distinguishing parameters?

For instance:
[UseCase('Pipeline Input',DistinguishingParameters='InputObject')]
[UseCase('Standard Path',DistinguishingParameters='Path')]
[UseCase('Literal Path',DistinguisingParameters='LiteralPath')]

This is more readable in my mind, and you don't have to do a logic puzzle to figure out what's going on.

[DerpMcDerp]

Often times when I use ParameterSets, the internals of the cmdlet are so different that it would be more convenient if PowerShell could use multimethods on cmdlets instead rather than having me clutter the internals of the begin, process, and end blocks with if tests to do my own dispatching.

I'd rather have multiple dispatch on cmdlets rather than this feature which just slightly tweaks ParameterSets.

[mattmcnabb]

I'd like to clarify - This RFC is only for Powershell classes, right? Not for Advanced Functions or Cmdlets?

If so, I tend toward the proposed usage of [MutuallyExclusive()], although I'd like to see the attribute in the class definition rather than outside of it.

[MikeShepard]

The "motivation" section mentions parameters for advanced functions as well.

[replicaJunction]

While I could see the [MutuallyExclusive()] attribute making sense in a class, when writing an advanced function, this would separate part of the definition of each parameter from the parameter itself. This doesn't make sense from an organizational standpoint, and it also makes the code more difficult to read.

Here's an example of an advanced function, with the MutuallyExclusive attribute added before the start of the function. When going over parameter definitions, it's tough to see which parameters are mutually exclusive, since that attribute is placed in a completely different place than the parameter attributes.

# Prop2 and Prop3 are mutually exclusive
[MutuallyExclusive("Prop2", "Prop3")]
function Invoke-Stuff {
    [CmdletBinding(DefaultParameterSetName = 'ParameterSet1',
                   SupportsShouldProcess = $true)]
    param(
        [Parameter(ParameterSetName = 'ParameterSet1',
                    ValueFromPipeline = $true,
                    ValueFromPipelineByPropertyName = $true)]
        [Alias('p1')]
        [String] $Prop1,

        [Parameter(ParameterSetName = 'ParameterSet1',
                    Mandatory = $true,
                    Position = 0)]
        [Alias('p2')]
        [ValidateScript({Test-Path $_})]
        [string] $Prop2,

        [Parameter(Mandatory = $false)]
        [Alias('p3')]
        [ValidateNotNullOrEmpty()]
        [string] $Prop3,

        [Parameter(ParameterSetName = 'ParameterSet2')]
        [Alias('p4')]
        [string] $Prop4
    )

    # ...
}

I like the ExclusionSet suggestion much better, since this becomes a parameter attribute. This can be logically placed with all the other attributes of each parameter.

[smokedlinq]

Alternate suggestion, use ParameterSet attribute that defaults like adding a [Parameter(ParameterSetName='Name')] attribute, also include the ability to write a negative parameter set, e.g. [ParameterSet(Exclude='Name')] would mean all parameter sets except Name, or alternatively accept multiple parameter set names [ParameterSet('Set1','Set2')] for explicit set definitions.

class Fu
{
    [ParameterSet('ByName')]
    [string] $Name

    [ParameterSet('ById')]
    [string] $Id

    [Ensure] $Ensure = ([Ensure]::Present)
    [string] $Description

    # Don't allow DisplayName when Name is used
    [ParameterSet(Exclude='ByName')]
    [string] $DisplayName
}

function Set-TargetResource
{
    [CmdletBinding()]
    param
    (
        [Parameter(Mandatory)]
        [ParameterSet('ByName')]
        [string] $Name,

        [Parameter(Mandatory)]
        [ParameterSet('ById')]
        [string] $Id,

        [Ensure] $Ensure = ([Ensure]::Present),
        [string] $Description,

        [ParameterSet(Exlcude='ByName')]
        [string] $DisplayName,
    )
}

[SteveL-MSFT]

@mattmcnabb intent is that this would be for both functions and classes. I realize now that the sample only shows for classes, but the attributes would be the same for functions

[mattmcnabb]

@SteveL-MSFT Quite all right, I see now that the header title mentions functions as well. Thanks!

[ckennedy666]

I strongly support @adweigert suggestion. This seems far better, clearer, and more in the spirit of attributes than that put forward in the RFC. Frankly both alternatives in the RFC just seem to complicate things more than necessary.

[MikeShepard]

I especially like @adweigert suggestion that we could include multiple parameter sets in the same attribute. Not being able to do so introduces a need for duplicating the rest of the parameter attributes.

[SteveL-MSFT]

@adweigert Good suggestion, however, it seems that the problem you are trying to solve is not exactly the same as the intent of this RFC. We'll update the RFC to clarify the intent as well as adding some real examples based on invoke-command and/or where-object. Hopefully we'll get this out before the holidays.