ConvertFrom/To-Hashtable and/or ConvertTo-PSCustomObject cmdlets

[joeyaiello]

Related discussion in #109, specifically this comment:

Finally got around to reviewing this with @PowerShell/powershell-committee.

It sounds like the problem that's being solved here is to convert nested hashtables to PSCustomObjects when the keys are all strings (when they're not strings, conversion will likely result in key collision due to ToString() returning type names).

To that end, we think it's more generically useful to build a ConvertFrom-Hashtable cmdlet that would allow more generic and custom conversion of hashtables to PSCustomObjects and potentially other types using constructors that expect specific hashtable "schemas". Another possible implementation is to do a ConvertTo-PSCustomObject that does more custom handling (and these aren't mutually exclusive). Additionally, a ConvertTo-Hashtable is probably useful.

We don't have this on our radar right now, but if someone wants to give a go at a ConvertFrom-Hashtable RFC and implementation, go for it.

We think the scenario we're trying to address is primarily casting nested hashtables of hashtables into PSCustomObjects (or possibly even other types).

[Jaykul]

Are we really trying to convert between hashtables and objects, or is this for serialization?
That is, do you want actual hashtables, or string representation of hashtables?

If it's the later, a very robust version of this already exists in the Configuration module (specifically, in it's MetaData submodule, but exported by Configuration).

If you want recursive conversion of live objects, I could extract that into a function and expose it, but it's currently not accessible.

[rjmholt]

I think the need here is for:

• An API to convert an object in PowerShell to PowerShell hashtable literal string notation (PSD syntax). Mostly with actual System.Collections.Hashtable objects, but could see use in other cases
• Another API to convert from the string back to a PSCustomObject or S.C.Hashtable.

The only complexity I see here is that PSD can have dynamic bits in it (@{ X = if (2 -gt 4) { 'Hi' } else { 'Bye' } }) since a PSD1 file is parsed in Restricted Language Mode, but otherwise I think this is basically a call for a PSD-syntax version of ConvertTo/From-Json

[rjmholt]

The only complexity I see here is that PSD can have dynamic bits in it (@{ X = if (2 -gt 4) { 'Hi' } else { 'Bye' } }) since a PSD1 file is parsed in Restricted Language Mode, but otherwise I think this is basically a call for a PSD-syntax version of ConvertTo/From-Json

Seeing this again, this part is wrong. The Restricted Language Mode is only true of module manifests. However, it does raise the question of whether a module manifest with such dynamic fields should be expected to parse with one of the proposed cmdlets

[vexx32]

Could always have a -Strict or -RestrictedLanguage switch on the cmdlet to enable that option.

[rjmholt]

Could always have a -Strict or -RestrictedLanguage switch on the cmdlet to enable that option.

Yeah the latter is what I'm imagining. I already wrote a little parser for the strict version. I just need to publish it somehow... The RLM version means taking a dependency on the PowerShell runtime, which I'm less keen on, but should be ok in the cmdlet.

I'd like to break it up into the core library and the cmdlet, with the cmdlet able to also parse RLM