Powershell: [Parameter] attribute additions

[vexx32]

Summary of the new feature/enhancement

1: ParameterSetName

Currently

ParameterSetName is very long, wordy, and redundant in its name, given that it's specifically attached _to_ a Parameter attribute.

param(
    [Parameter(Position = 0, Mandatory, ParameterSetName = 'MySet')]
)

This seems super unnecessary and makes for attribute declarations that become kind of unwieldy.

Proposal

We could implement either:

1. Support for the [Alias()] attribute on attribute members when matching names supplied in the attribute declaration.
2. Add a ghost property (getter/setter pointing back at the original property).

I'd propose a shorter name such as simply SetName as being entirely sufficient. I feel there's no need to completely restate Parameter in ParameterSetName.

param(
    [Parameter(Position = 0, Mandatory, SetName = 'MySet')]
    $MyParam
)

2: ValueFrom* Properties

These are also very wordy and could, I feel, be improved from a usability standpoint without really losing out on verbosity. If this were an Enum[] property it would be significantly simpler to state and much less lengthy.

Currently

param(
    [Parameter(Position = 0, Mandatory, ValueFromPipeline, ValueFromPipelineByPropertyName, ValueFromRemainingArguments)]
    $MyParam
)

param(
    [Parameter(Position = 0, Mandatory, ValueFrom = 'Pipeline', 'PipelineByPropertyName')]
    $MyParam
)

Again, this could be implemented without removing the existing ones by simply having the setter for this property set the related existing properties. It would exist simply to make it significantly simpler to write _and_ read these declarations.

Thoughts? 😄

[FriedrichWeinmann]

I think this is eminently worth doing and would improve readability

[Graham-Beer]

I like this as well and doesn't effect backwards compatibility.

[iSazonov]

I think duplication (aliasing) in any form of language constructions is bad practice which turns a language into a secret cipher. It just kills readability.
Modern IDEs with IntelliSense save us from typing long names. And modern best practice is to use self-descriptive names that can be long. So I'd consider the issue as "by design and won't fix".
It is worth noting that this design is very simple and straightforward. And it has a significant problem that we should really solve - _it cannot describe any complex set of parameters_. As a result, we are forced to use dynamic parameters or, more often, simply add logic to the code to say which parameters can be used together and which not (with lost tab completion).
There is another scenario that we cannot implement for this reason - tab completion for native commands.
I suggest not to waste time on cosmetic aliasing but focus on creating a new design. (With new names, maybe short :-) )

[vexx32]

@iSazonov do you have concrete proposals for what such a new design would entail? Sounds interesting 😄

[KirkMunro]

I'm against this for several reasons:

1. It creates more work for toolmakers without adding value.
2. It creates unnecessary duplication.
3. I'm not convinced that the proposed alternative enhances discoverability nor do I think it makes it easier to learn.
4. ParameterSetName is clear. SetName is not.

[vexx32]

1 & 2, fair.

3 -- maybe? It's easier to write and read imo.
4 -- in the context it'll be used, it's perfectly clear. [Parameter(SetName = 'Set2')]

[KirkMunro]

1. Parameters have ValidateSet. Part of your proposal even suggested putting validators inside of the Parameter attribute. Suddenly you have multiple "Set" terms that could be confused. OTOH ParameterSetName is clear and unambiguous.

[vexx32]

Not sure what you mean. I wasn't proposing putting validators in the Parameter attribute. 😕

[KirkMunro]

Sorry, crossed wires. I blame the fact that it's approaching midnight here. But regardless, I like the explicit distinction that ParameterSetName gives me. SetName feels...not specific enough, and a potential point of confusion.

[vexx32]

🤷‍♂ it's not like what I propose would _stop_ you from using the full name. I just feel it's unnecessarily redundant in the Parameter attribute to have a property that has Parameter as a prefix as well.

[iSazonov]

do you have concrete proposals for what such a new design would entail? Sounds interesting

I do not know the solution and so far I only see difficulties with the current attributes.

• Existing tools are very simple to create one-two level parameter sets.
• Further complexity grows exponentially. We have to apply dynamic parameters, which can also be difficult and inconvenient. As well as perform special processing in the begin block.
• It is also impossible (relatively speaking) to create a single set of parameters for several cmdlets like Path, LiteralPath, Encoding (that resembles interfaces).
• This could work also for external commands so that we could implement tabcompletion for them.

Ideally, this could be a single attribute (cmdlet/wrapper class) with definitions based on some notation and a parser. I guess it is not too difficult. The main difficulty will arise with the integration into the existing binding mechanism without regressions.