In part two of this web series about powershell classes, I would like to talk about how to use a powershell enum and go through a use case which will point out their use, and why you really want to integrate them into your scripts.
If you have missed the beginning of this blog post series, or if you are new to powershell classes, See part one here, and learn how powershell constructors and their overloads works in powershell 5 classes.
how to write a powershell enum to use in a powershell class
Since version 5 of powershell, we have the possibility to create powershell enumerations. Or more commonly called powershell enum.
What is a powershell enum? why would we even want to use a powershell enum? How do we create a powershell enum?
I’ll try to answer all of these questions in this blog post.
If you would like to see something to be covered more in depth, please let me know in the comment section below or tweet me at @stephanevg
The very basics for a powershell Enum to exist would be to having something as represented as followed:
To create a new powershell enumartion, we will use the new keyword “Enum“.
The very basics for a powershell Enum to exist would be to having something as represented as followed:
A powershell enum is used to offer a limited list of elements of a specefic type to your object.
For example, you could have a Enum called “ServerType” that would contain a list of all of your different type of servers. These are the ones that I have my lab, and which we will build the example.
When you would like to have a reference to one of you elements from your list you will query it as followed:
This would return the value “ConfigMgr”
See by your self in the example below:
powershell Enum
The value that is returned, is of type [ServerType], which we can use to include generic validation logic to our powershell code and by keeping it easily extensible.
I can imagine this to be used like some sort of ‘externalized parameter set‘ which can easily be modified, without impacting to drastically your code when we add a new server type to manage. The same powershell enum can then be used in several different places in our code while limiting copy pasting.
Now imagine this: Let’s say you have an IF ($variable) {} condition in your code, and want to make sure that the value of $variable is part of a pre-defined list. You could sure use a text file to store the information in, xml, JSON or even a validateSet in your advance functions. If the if statement is equal to one of the values of your list, or let’s say, a specific value of the list, you want to execute some appropriate code. To do so, you would have to either use of bunch of if’s and elseif’s , a Switch, or/and a foreach construct.
Confusing right? Hang on, and look at the example below.
Let’s say, you have a new server type, like, for example a SCOM server, that would mean that you would have to adapt your if’s or your switch statements. Now if we do or methods like above, we can restrict it on the type and avoid us to adapt our main code. Using powershell enums will give quite some easy extensibility to our code.
Instead of having something like this:
We could do something as simple as this:
The advantage of the second method, is that to extend the functionality of our script to accept a new type of server, the only thing we need to do is to add new entry to the Enum Class.
Using the ‘-is‘ operator combined with a Enum Type, allows to check if several conditions are true, using a way more compact syntax.We are checking the type, instead of the real content, and leaving the door open to add new servertypes without impacting our inner logic.
Powershell enum contains constants:
We can also use a powershell enum to assign a value to each of the properties that composes the powershell enum, but there is an important thing to keep in mind: A powershell Enum can only be a constant.
A powershell enum can only contain constants. This means it cannot be a word, or the result of some query.
The code below assigns a constant to each value.
We can later on cast a value to the type of our powershell enum (in my example [ServerEnvironment]) and we will have the corresponding environment back.
Constant can be assigned in any order, but it is not an obligation. By default, if you omit to put constants on your enums, they will still be accessible as in the example above. The only thing to keep in mind is that a powershell enum is 0 based.
One last thing to add to this, is the fact that you can add constants to your powershell enum, that does not necessarily starts at 0. In other words, you will be able to use your powershell enum as followed as well:
As a last point, and as explained above, it is possible to use integers to point to specific values of our Enum’s (Or better said, to their values).
Now, it is also possible to retriew their assigned values, based on their value. As usual, an example will make this clearer:
Sometimes, having access to the assigned value of your Enum might be more important than the Enum it self. Well, this got you covered.
This was actually implicitly suggested on reddit. Read the full comment on reddit here