Some Questions about your code

I had this comment left on my blog related to a tweet announcing the availability of the 0.5 version of PowerShell Admin Modules.

It raises a few interesting questions so I decided to reproduce it in full.  Thanks to Thomas for the questions.  I’ve put my answers in line in blue.

Some Questions about your code:

1)

$bustype = DATA {

-> Keyword DATA:  what is this about? How do you call this Technique (So i can google for?) Are there more Keywords beside DATA?

 

The DATA keyword was introduced in PowerShell 2.  A DATA block is used to isolate text strings and other read-only data from the script code.  See Get-Help about_Data_Sections for more information. 

Other keywords include

Begin, Break, Catch, Continue, Data, Do, Dynamicparam, Else, Elseif, End, Exit, Filter, Finally, For, Foreach, From, Function, If, In, Param, Process, Return, Switch, Throw, Trap, Try, Until, While   

see get-help about_language_keywords for details


2)

Think that you used: 
$bustype = DATA { ... ConvertFrom-StringData
and not just a Hashtable like:

$bustype = @{
-1 = "Undefined"
0 = "Internal"
1 = "ISA"
2 = "EISA
}

is , because you just did not like to write the " "  or is ther another special reason why you did that? Think Both way's produce a Hashtable as far as i saw it.

 

You are correct both ways will produce a hash table. I have been creating a lot of hash tables recently for WMI lookup functions. The values are in a table in the WMI documentation. It is less typing to create it the way I did

$bustype = DATA {
ConvertFrom-StringData -StringData @'
-1 = Undefined
0 = Internal
1 = ISA
2 = EISA
'@
}

especially as I have a template for the code snippet to create the hash table. I also think it is easier to read. It has a bonus of introducing the Convertfrom-StringData cmdlet.


3)
And My last question is, why you placed the $bustype assignment outside your function and not inside?

 

I put the $bustype assignment outside the function so that it is ( a ) available to other functions if needed. Its only created once when the module loads rather than every time the function runs.


Hope you find some minutes to answer my questions ;-)

 

Actually Question Nr 4. about Modules in General came into my mind while writing this Email :-)

4)
You have Several Modules PAMSysInfo, PAMShares, .... I all would place in my modules Folder and then load with Import-Module..

I think i will also split up my scripts to multiple Modules.
What i like to do finally if possible is Following:

Having a Folder WindowsPowershell\Modules\PAM , and there are my "Sub"ModulesFolder  WindowsPowershell\Modules\PAM\PAMSysInfo,  WindowsPowershell\Modules\PAM\PAMShares, ...

In the PAM folder itself i have a Preference File where i set the individual Submodules to load or not e.g.

ModulesToImport = @{                           
                PAMSysInfo     = $true         
                PAMShares   = $true
        PAMbla    = $false
               }

So with a "Import-Module PAM" , all specified SubModules would be loaded. (Like said before, if this is Possible at all ;-) )
Maybe you like the idea as well for your PAM Modules.. I Think PSCX uses such a technique but i had just a very quick look to PSCX Structure..

I am looking at a overall module that will load the sub modules. It will either be editable or I’ll supply switches to only include specific modules (or maybe not include specific modules)

Hope this helped

Leave a Reply