Repository navigation
ConvertFrom/To-Hashtable and/or ConvertTo-PSCustomObject cmdlets #159
Description
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).
Activity
Jaykul commentedon Jun 28, 2019
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 commentedon Jun 28, 2019
I think the need here is for:
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-Jsonrjmholt commentedon Jul 30, 2020
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 commentedon Jul 30, 2020
Could always have a
-Strictor-RestrictedLanguageswitch on the cmdlet to enable that option.rjmholt commentedon Jul 30, 2020
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