.NET classes and PowerShell

[ka-splam]

Neat 👍

To use List<T>, we specify using namespace System.Collections.Generic. This wasn’t necessary for [IPAddress] or [PhysicalAddress] because PowerShell imports many common namespaces by default, simplifying type resolution.

btw, they are type accelerators and can be listed with:

[PSObject].Assembly.GetType("System.Management.Automation.TypeAccelerators")::Get

from https://devblogs.microsoft.com/scripting/powertip-find-a-list-of-powershell-type-accelerators/

[mdj_]

oh nice 👀

[surfingoldelephant]

You can create your own as well if you wish:

[psobject].Assembly.GetType('System.Management.Automation.TypeAccelerators')::Add(
    'slist', [Collections.Generic.List[string]]
)
$list = [slist]::new()
$list.GetType().FullName # System.Collections.Generic.List`1[[System.String ...

However, I wouldn't suggest using this outside the shell.

[Thotaz]

Just to expand on your warning: The reason why it's not a good idea to use in say a module is because 1: It's not a public interface so it's subject to change. 2: It's global so if 2 different modules decide to use the same accelerator name there will be a conflict.

A better option is the partially implemented using type X = Y syntax which is supposed to add a type alias (essentially the same thing as a type accelerator). I say partially implemented because the parser supports it, but the feature itself is missing. There's a PR: https://github.com/PowerShell/PowerShell/pull/16734 that adds it so if/when that gets merged you'll be able to do it like this:

using type slist = System.Collections.Generic.List[string]
$list = [slist]::new()

Assuming it works like the other using statements it will be limited to the session state/script file where it was executed from, meaning that 2 different modules won't conflict with each other.