Declare Dynamic Parameters without RuntimeDefinedParameterDictionary #20527

dkattan · 2023-10-19T18:38:17Z

PR Summary

One of the difficulties in declaring dynamic parameters is the requirement of the RuntimeDefinedParameterDictionary that requires the duplication of the parameter name both in the RuntimeDefinedParameter and the key of the RuntimeDefinedParameterDictionary.

This PR allows you to declare dynamic parameters by emitting them to the output stream.

This is the approved part of #20069 (comment)

Before

Function Test-DynamicParameter {
    [CmdletBinding()]
    Param(
        [Parameter(Mandatory = $true, ValueFromRemainingArguments = $true)]
        $Remaining
    )
    dynamicparam {
       $RuntimeParameterDictionary = [Management.Automation.RuntimeDefinedParameterDictionary]::new()        
       $RuntimeParameterDictionary.Add("Foo", ([Management.Automation.RuntimeDefinedParameter]::new(
                    "Foo",
                    [string],
                    @([Parameter]::new())
                )))
        $RuntimeParameterDictionary.Add("Bar", ([Management.Automation.RuntimeDefinedParameter]::new(
                    "Bar",
                    [string],
                    @([Parameter]::new())
                )))        
        return $runtimeParameterDictionary
    }
    process {
        $PSBoundParameters | Format-Table
    }
}

After

Function Test-DynamicParameter {
    [CmdletBinding()]
    Param(
        [Parameter(Mandatory = $true, ValueFromRemainingArguments = $true)]
        $Remaining
    )
    dynamicparam {
        [Management.Automation.RuntimeDefinedParameter]::new(
            "Foo",
            [string],
            @([Parameter]::new())
        )
        [Management.Automation.RuntimeDefinedParameter]::new(
            "Bar",
            [string],
            @([Parameter]::new())
        )
    }
    process {
        $PSBoundParameters | Format-Table
    }
}

Access CommentElements from dynamicparam block

Function Test-DynamicParameter {
    [CmdletBinding()]
    Param(
        [Parameter(Mandatory = $true, ValueFromRemainingArguments = $true)]
        $Remaining
    )
    dynamicparam {
        # $Input will contain the command elements of the current invocation.
        # $_ will be the current command.

        # $Input will contain the command elements of the current invocation.
        # $_ will be the current command.
        $pathToBe = @($input)[1]

        # This is a simple and easily testable example, and not anywhere near complete parsing
        # (this check will only work if $Path is assigned positionally)
        if ($pathToBe -is [Management.Automation.Language.StringConstantExpressionAst]) {
            $pathToBe = $pathToBe.Value
        }

        # If the path is not explicitly "badPath"
        if ($pathToBe -ne "BadPath") {
            # create a dynamic parameter
            [Management.Automation.RuntimeDefinedParameter]::new(
                "foo",
                [int],
                @([Parameter]::new())
            )
        }
    }
    process {
        $PSBoundParameters | Format-Table
    }
}

PR Checklist

microsoft-github-policy-service · 2023-10-27T03:22:40Z

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

pull-request-quantifier-deprecated · 2024-02-19T15:33:19Z

This PR has 378 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Large
Size       : +244 -134
Percentile : 77.8%

Total files changed: 5

Change summary by file extension:
.cs : +119 -89
.ps1 : +125 -45

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-19T15:36:06Z

This PR has 9148 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +2309 -6839
Percentile : 100%

Total files changed: 167

Change summary by file extension:
.yml : +12 -13
.props : +3 -3
.md : +424 -78
.json : +95 -34
.txt : +311 -307
.wxs : +18 -0
.psm1 : +70 -14
.config : +1 -1
.csproj : +41 -40
.cs : +495 -5692
.resx : +15 -375
.ps1 : +784 -236
.psd1 : +40 -46

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

…inedParameters

pull-request-quantifier-deprecated · 2024-02-19T15:40:12Z

This PR has 378 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Large
Size       : +244 -134
Percentile : 77.8%

Total files changed: 5

Change summary by file extension:
.cs : +119 -89
.ps1 : +125 -45

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

…out-runtimedefinedparameterdictionary

dkattan mentioned this pull request Oct 19, 2023

Dynamic param without runtime defined parameter dictionary MicrosoftDocs/PowerShell-Docs#10551

Closed

4 tasks

dkattan changed the title ~~Declare dynamic parameters without runtimedefinedparameterdictionary~~ Declare Dynamic Parameters without RuntimeDefinedParameterDictionary Oct 19, 2023

microsoft-github-policy-service bot added the Review - Needed The PR is being reviewed label Oct 27, 2023

dkattan mentioned this pull request Nov 17, 2023

Dynamic Parameters are too Difficult to Construct #20395

Open

7 tasks

pull-request-quantifier-deprecated bot added the Large label Feb 19, 2024

dkattan force-pushed the declare-dynamic-parameters-without-runtimedefinedparameterdictionary branch from b38a202 to bc0a412 Compare February 19, 2024 15:35

dkattan requested review from TravisEz13, adityapatwardhan, anmenaga and daxian-dbw as code owners February 19, 2024 15:35

pull-request-quantifier-deprecated bot added Extra Large and removed Large labels Feb 19, 2024

dkattan added 3 commits February 19, 2024 09:38

Proof of Concept

941a42a

Removed unintentional whitespace changes

6939563

Removed need for RuntimeParameterDictionary wrapper around RuntimeDef…

70ee287

…inedParameters

dkattan force-pushed the declare-dynamic-parameters-without-runtimedefinedparameterdictionary branch from bc0a412 to 70ee287 Compare February 19, 2024 15:40

pull-request-quantifier-deprecated bot removed the Extra Large label Feb 19, 2024

pull-request-quantifier-deprecated bot added the Large label Feb 19, 2024

Merge branch 'PowerShell:master' into declare-dynamic-parameters-with…

742e6cc

…out-runtimedefinedparameterdictionary

StevenBucher98 added the WG-Engine core PowerShell engine, interpreter, and runtime label Jul 18, 2024

dkattan mentioned this pull request Aug 15, 2024

Working Group Member Request #24168

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Declare Dynamic Parameters without RuntimeDefinedParameterDictionary #20527

Declare Dynamic Parameters without RuntimeDefinedParameterDictionary #20527

Uh oh!

dkattan commented Oct 19, 2023 •

edited

Loading

Uh oh!

microsoft-github-policy-service bot commented Oct 27, 2023

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 19, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 19, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 19, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Declare Dynamic Parameters without RuntimeDefinedParameterDictionary #20527

Are you sure you want to change the base?

Declare Dynamic Parameters without RuntimeDefinedParameterDictionary #20527

Uh oh!

Conversation

dkattan commented Oct 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Before

After

Access CommentElements from dynamicparam block

PR Checklist

Uh oh!

microsoft-github-policy-service bot commented Oct 27, 2023

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 19, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 19, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Feb 19, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dkattan commented Oct 19, 2023 •

edited

Loading