Assert would typically be used at the beginning of a pipeline to test if a particular entity existed (and possibility, met specific additional requirements).
Assert can also be be used mid-pipeline or at the end of the pipeline as a post-execution verification that an entity was created (e.g. a user, a file, a backup, ...), etc.
I'm still thinking through Microsoft's strategy/desire to standardize on a relatively fixed set of verbs in PowerShell. Take the Data verbs for example: http://msdn2.microsoft.com/en-us/library/ms551957.aspx.
What is the real difference between Backup, Export and Out?
All three serialize, persist and commit an entity to some
data store (or via a pipeline, pipe the data to the next cmdlet).
They really only differ in the format of the serialization and perhaps, any additional metadata that is created to describe the serialized output.
Does PowerShell need all three? IMHO, not really.
Microsoft is strongly encouraging developers of PowerShell add-ons (MMC Snapins, Cmdlets and Providers) to adhere to a minimal set of cmdlet verbs (and nouns) and has published the following set of Required (Must Have) guidelines: http://msdn2.microsoft.com/en-us/library/ms714657.aspx. They are also wrestling internally was to what is the right set of standard verbs.
Take "New" for example. The claim is that New is an example of a universal, well understood verb that is prevalent in most applications today (e.g. File->New, AD-New User, Windows Explorer->New Folder, etc).
Should these types of patterns apply to the PowerShell scripting language used for application
systems administration and related utility applications? My answer is: not necessarily.
The key difference between the use of New in a traditional windowed application vs. a script or command-line application is that most windowed applications don't actually create anything when you click File-New -- rather they create an in-memory representation of the entity (e.g. Word document, User object) that is not named, serialized, persisted or
committed to a data store until user performs a number of additional interactive actions and finally saves the entity.
However, in a (non-interactive) script or command-line console application use for application and systems
administration, I offer that it is critically important that the script's intention be crystal clear: readable, understandable and precise in its execution semantics.
I refer to this as "precision scripting" (vs. "generic scripting").
I believe Microsoft should be encouraging practices that support precision
scripting (and not generic scripting).
One solution is to use precise verbs that are less open to vague semantic interpretation on the part of the system administrator. For example, the following is a more precise set of verbs more suitable for precision scripting: Create, Replace, Update, Delete, Merge and Add.
|
Precise Verb |
Verb
Description |
Pre-delete Existing Item |
Create New Item |
|
Create |
Create creates a new instance of the exported
item; or fails if the item already exists (see replace, update and add) |
No |
Yes |
|
Delete |
Delete deletes an existing item imported into
SPS2003 during a previous execution of the Import tool; or fails if the
item doesn’t exist. |
No |
No |
|
Replace |
Replace replaces an existing item imported
intoSPS2003 during a previous execution of the Import tool by executing
a Delete followed by a Create; or fails if the item doesn’t exit. |
Yes |
Yes |
|
Update |
Update adds or replaces the values of
selected attributes of an existing item imported intoSPS2003 during a
previous execution of the Import tool; or fails if the item doesn’t
exit. |
No |
No |
|
Add |
Add a) creates a new instance of the
exported item if the item does *not* exist; or b) replaces an
item if the item was imported into SPS2003 during a previous execution
of the Import tool. This operation shouldn’t fail based on previous
import operations |
a) No
b) Yes
|
a) Yes
b) Yes
|
|
Merge |
Add a) creates a new instance of the
exported item if the item does *not* exist; or b) updates an item
if the item was imported into SPS2003 during a previous execution of the
Import tool. This operation shouldn’t fail based on previous import
operations |
a) No
b) No
|
a) Yes
b) No
|
Custom Iterators: http://msdn2.microsoft.com/en-us/vcsharp/bb264519.aspx
Anders Video on LINQ: http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx
MmcListView - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/managedMMC/html/41939cc2-3fb4-4a5c-82fe-00ed92f25df1.asp