Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Add support for dynamic parameter declaration in param() #16173

Copy link
Copy link
@TobiasPSP

Description

@TobiasPSP
Issue body actions

Summary of the new feature / enhancement

Static parameters can easily be defined declarative inside a param() structure.
Dyamic parameter is not directly supported and must be programmed inside a dynamicparam section of a scriptblock. This requires deep knowledge of intrinsic types and concepts.

By adding a new attribute [Dynamic()], parameters can easily be declared as being dynamic. The attribute could take a scriptblock as argument to specify the condition under which the dynamic parameter would show.

param
(
    # regular static parameter
    [string]
    $Normal,
        
    # show -Lunch only at 11 a.m. or later
    [Dynamic({(Get-Date).Hour -ge 11})]
    [switch]
    $Lunch,
        
    # show -Mount only when -Path refers to a local path (and not a UNC path)
    [string]
    $Path,
        
    [Dynamic({$PSBoundParameters['Path'] -match '^[a-z]:'})]
    [switch]
    $Mount
)

Here is a working example and a proof of concept (hosted in the gallery) that shows how dynamic parameters could be leveraged this way:

https://github.com/TobiasPSP/Modules.dynpar/blob/main/README.md

It would be awesome if both the attribute [Dynamic()] and the auto-generation of the code would one day be natively integrated in PowerShell so users would just need to choose which of their parameters should be dynamic, and when.

Proposed technical implementation details (optional)

Technical implementation available here: https://github.com/TobiasPSP/Modules.dynpar/blob/main/README.md

Reactions are currently unavailable

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bugResolution-Won't FixThe issue won't be fixed, possibly due to compatibility reason.The issue won't be fixed, possibly due to compatibility reason.WG-Languageparser, language semanticsparser, language semantics

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.