With every new property you added to your object, $pocketknife has been gradually taking shape, but it still really can't do anything. Properties only describe what an object is, not what it can do.
The actions your object can do are called its methods. So let's teach your object a few useful methods:
# Adding a new method:
Add-Member -memberType ScriptMethod -In $pocketknife ` -name cut -Value { "I'm whittling now" }
# Specify arguments without parameter names by position data:
Add-Member -in $pocketknife ScriptMethod screw { "Phew...it's in!" }
# Specifying "InputObject" directly through the pipeline:
$pocketknife | Add-Member ScriptMethod corkscrew { "Pop! Cheers!" }
Again, you used the Add-Member cmdlet, but this time you added a method instead of a property (in this case, a ScriptMethod). The value is a scriptblock marked by braces, which contains the
PowerShell instructions you want the method to perform. If you output your object, it will still look the same because PowerShell only visualizes object properties, not methods:
$pocketknife
Color Weight Manufacturer Blades --- --- --- ---Red 55 Idera 3
To use any of the three newly added methods, add a dot and then the method name followed by two parentheses, which are what distinguish properties from methods. For example, if you'd like to remove a cork with your virtual pocketknife, enter this instruction:
$pocketknife.corkscrew() Pop! Cheers!
Your object really does carry out the exact script commands you assigned to the corkscrew() method. So, methods perform actions, while properties merely provide information. Always remember to add parentheses to method names. If you forget them, something interesting happens:
# If you don't use parentheses, you'll retrieve information on a method:
$pocketknife.corkscrew
Script : "Pop! Cheers!"
OverloadDefinitions : {System.Object corkscrew();}
MemberType : ScriptMethod TypeNameOfValue : System.Object
Value : System.Object corkscrew();
Name : corkscrew IsInstance : True
You just received a method description. What's interesting about this is mainly the
OverloadDefinitions property. As you'll see later, it reveals the exact way to use a command for any method. In fact, the OverloadDefinitions information is in an additional object. For PowerShell, absolutely everything is an object so you could store the object in a variable and then specifically ask the OverloadDefinitions property for information:
# Information about a method is returned in an object of its own:
$info = $pocketknife.corkscrew
$info.OverloadDefinitions System.Object corkscrew();
The "virtual pocketknife" example reveals that objects are containers that contain data (properties) and actions (methods).
Our virtual pocketknife was a somewhat artificial object with no real use. Next, let's take a look at a more interesting object which PowerShell stores in the variable $host.
Properties: What an Object "Is"
Properties describe an object. Object properties are automatically converted into text when you output the object to the console. That's enough to investigate any object. Check out the properties in $host!
$host
Name : ConsoleHost Version : 1.0.0.0
InstanceId : e32debaf-3d10-4c4c-9bc6-ea58f8f17a8f UI : System.Management.Automation.Internal.
Host.InternalHostUserInterface CurrentCulture : en-US
CurrentUICulture : en-US
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
The object stored in the variable $host apparently contains seven properties. The properties' names are listed in the first column. So, if you want to find out which PowerShell version you're using, you could access and return the Version property:
$host.Version
Major Minor Build Revision --- --- --- ---1 0 0 0
It works—the version is displayed. However, the version isn't displayed as a single number. Rather, PowerShell displays four columns: Major, Minor, Build and Revision. Whenever you see columns, you know these are the object properties that PowerShell has just converted into text. Let's check out the data type that the Version property uses:
$version = $host.Version
$version.GetType().FullName System.Version
The version is not stored as a String object but as a System.Version object. This object type is perfect for storing versions, allowing you to easily read all details about any given version:
$host.Version.Major 1
$host.Version.Build 0
Knowing an object type is very useful because once you know there is a type called System.Version, you can use it for your own purposes as well. Try and convert a simple string of your choice into a rich version object! To do that, simply make sure the string consists of four numbers separated by dots (the typical format for versions), then make PowerShell convert the string into a
System.Version type. You convert things by adding the target type in square brackets in front of the string:
[System.Version]'12.55.3.28334' Major Minor Build Revision --- --- --- ---12 55 3 28334
The CurrentCulture property is just another example of the same concept. Read this property and find out its type:
$host.CurrentCulture
LCID Name DisplayName ---- ----
---1033 en-US English (United States)
$host.CurrentCulture.GetType().FullName System.Globalization.CultureInfo
Country properties are again stored in a highly specialized type that describes a culture with the properties LCID, Name, and DisplayName. If you wanted to know which international version of PowerShell you are using, read the DisplayName property:
$host.CurrentCulture.DisplayName English (United States)
$host.CurrentCulture.DisplayName.GetType().FullName
System.String
Likewise, you could convert any suitable string into a CultureInfo-object. So if you wanted to find out details about the 'de-DE' locale, do this:
[System.Globalization.CultureInfo]'de-DE'
LCID Name DisplayName ---- ---- ---1031 de-DE German (Germany)
You could also convert the LCID into a CultureInfo object by converting a suitable number:
[System.Globalization.CultureInfo]1033
LCID Name DisplayName ---- ----
---1033 en-US English (United States)