Poshoholic raises the question of PowerShell namespaces.
I’ve been thinking about this, too. I think it’s important for usability to keep the naming uncluttered, which is why you’ll find Get-VM as opposed to Get-VMWVM or some such in the VMworld presentation I posted last week.
That said, the potential for naming collisions isn’t something to simply dismiss and also plays into usability. I’ve been thinking along the same namespace lines as Kirk. It turns out that we already have some amount of namespace support in PowerShell as long as we’re talking about snapins. Based on that, here’s a strawman of something that might work today:
|
1 |
function Set-NameSpace {<br /> param($ns = $null)<br /><br /> $oldNamespace = @{}<br /> foreach ($key in $ns.Keys) {<br /> $oldMapping = Get-Command $key -CommandType Cmdlet -ErrorAction SilentlyContinue<br /> if ($oldMapping -ne $null) {<br /> $oldNamespace[$key] = $oldMapping.PSSnapin.Name + "\" + $oldMapping.Name<br /> } else {<br /> $oldNamespace[$key] = $null<br /> }<br /><br /> $newMapping = $ns[$key]<br /> if ($newMapping -eq $null) {<br /> del alias:$key<br /> } else {<br /> Set-Alias $key $ns[$key] -Scope 1<br /> }<br /> }<br /><br /> $oldNamespace<br />} |
Now imagine that each snapin defines a namespace mapping variable. To make it concrete, let’s imagine a snapin named foo that wants to use the names get-host and get-process itself. So that snapin defines its namespace mapping like this:
|
1 |
$fooNamespace = @{"get-host" = "foo\get-vmhost"; "get-process" = "foo\get-process"} |
With this, we can achieve the affect of a "using namespace" construct like this:
|
1 |
PS C:\ws\powershell> $old = set-namespace $fooNamespace<br />PS C:\ws\powershell> $old<br /><br />Name Value<br />---- -----<br />get-process Microsoft.PowerShell.Management\Get-Process<br />get-host Microsoft.PowerShell.Utility\Get-Host<br /><br /><br />PS C:\ws\powershell> get-process<br />Cannot resolve alias 'get-process' because it refers to term 'foo\get-process',<br /> which is not recognized as a cmdlet, function, operable program, or script fil<br />e. Verify the term and try again.<br />At line:1 char:11<br />+ get-process <<<<<br />PS C:\ws\powershell> get-host<br />Cannot resolve alias 'get-host' because it refers to term 'foo\get-vmhost', whi<br />ch is not recognized as a cmdlet, function, operable program, or script file. V<br />erify the term and try again.<br />At line:1 char:8<br />+ get-host <<<< |
So we see based on the errors that our invocations were in the correct "namespace" as we’re trying to invoke these cmdlets from the foo snapin. And now to stop using that namespace:
|
1 |
PS C:\ws\powershell> set-namespace $old | Out-Null<br />PS C:\ws\powershell> get-host<br /><br /><br />Name : ConsoleHost<br />Version : 1.0.0.0<br />InstanceId : d2f07d5a-8be5-45e8-9bf4-8e32b531f410<br />UI : System.Management.Automation.Internal.Host.InternalHostUserI<br /> nterface<br />CurrentCulture : en-US<br />CurrentUICulture : en-US<br />PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy |
This could be made much more like a "using namespace" construct as in Kirk’s post by passing the commands to be executed as a script block and resetting the namespace after execution.
Aside from that, this is obviously incomplete, not taking into account aliases instead of or in addition to cmdlets, etc. And it doesn’t work at all for functions which don’t have a snapin to distinguish them (any thoughts on alternatives?). But maybe it’s a reasonable strawman for dealing with the problem using existing mechanisms. What do you think? Better suggestions?
Antonio Dias
Update:
I used Get-Process and Get-Host as examples because we’re all familiar with them. This obviously isn’t an encouragement to stomp on existing names, just a thought exercise around alternatives to prefixing the nouns.
