Posts RSS Comments RSS 253 Posts and 411 Comments till now

cmdlet Design Suggestion

I wanted to make a case for using task based cmdlets instead of methods when designing Snapins. There have been several “Vendors” that have produced cmdlets for Powershell: Exchange, Citrix, VMWare, and IBM to name a few. Most have done very well here, but this is one thing I think the VMware team excelled at.

< sidebar >
As some of you may know, I have a long background in Active Directory. As an Ex-Microsoft Support Professional in the Directory Services Team and later a Rapid Response Engineer specializing in Active Directory, let’s just say I have passion for all things AD.
I was lucky enough to spend a significant amount of time with the DS team at MS responsible for the Powershell cmdlets they will release at some time in the future. While I cannot give any details I can say… OMG! I CANNOT WAIT to be able to talk about them.
< / sidebar >

Here is the basic Goal

Get-Something | Filter | Change-Something | Change-SomethingElse | Save-Something

The thing to avoid: Depending on methods for object task.
Get-Something | %{$_.DoSomething()}

Here is an Example of what I mean
Lets say we have a Car Object (class). The Car object has Properties like Make, Model, Color, TireCount, Size, and Type.
We also have things we can do with a car like start , turn off, stop, turn, load, and unload.

We could approach this by creating a Car class with the set properties and methods. This may seem simpler, but it is not intuitive for your typical Admin. Your typical admin does not want to do this

Get-Car | ?{$_.Type -eq "MiniVan"} | %{$_.LoadPeople()} | %{$_.Start()} | %{$_.Turn("Right")} | %{$_.Stop()} | %{$_.UnLoadPeople()}

Ideally from an Admin perspective a bunch of Task oriented cmdlets would be your best bet. Let’s assume you had these cmdlets instead of Methods:

Your admin can now do this

Get-Car |  ?{$_.Type -eq "MiniVan"} | Invoke-LoadCar | Start-Car | Invoke-TurnCar -Right | Stop-Car | Invoke-UnloadCar

This reads more like a sentence than a script syntax.

2 Responses to “cmdlet Design Suggestion”

  1. on 04 May 2008 at 12:16 amgkirkpatri

    Amazing, I was pondering just this issue today, and I have to disagree. Creating a cmdlet for every object and verb clutters the single flat cmdlet namespace terribly. If we truly made all methods cmdlets, we would be writing things like Get-Car | Get-Type $_ | Evaluate-Equality “MiniVan”… etc. Using methods provides a natural namespace scoped to the class of the object itself. It’s why OO languages are so much more manageable than, say, old-school Fortran or Cobol where there is a single global namespace for all functions.

    I think the reason that admins might find the cmdlet syntax more “intuitive” (nothing in computers is literally intuitive… maybe consistent or predictable is a better word) is that the PS syntax for invoking a method on the current pipeline object is so arcane. Is it really %{$_.DoSomething()}? Yecchhh. I’m no PS guru, but if $_.Property is reasonable,I don’t see the problem with $_.DoSomething().


  2. on 05 May 2008 at 1:39 pmhalr9000

    I have to side with Brandon on this one. I can certainly understand where gil is coming from, but during the training and feeding of a lot of Powershell newbies on the VMware Toolkit forum, I can say for sure that usability-wise this will please more admins. The funny thing for me is that just last night I was working on a chapter devoted to this very subject in my book. The section heading is “how to build a good pipeline”, and in it I make the case that most of the “power” in PowerShell is seen when you use streaming pipelined operations with cmdlets.

    Co-host, PowerScripting Podcast (

Trackback this post | Feed on Comments to this post

Leave a Reply

You must be logged in to post a comment.