Make `PSCustomObject` more `Dictionary` alike

[iRon7]

Summary of the new feature / enhancement

Use case:
I have a Complex Object¹⁾ like:

$MyObject | ConvertTo-Json -Depth 9
{
  "AllNodes": [
    {
      "NodeName": "localhost",
      "CertificateFile": ".\\DSCCertificate.Customer.cer"
    }
  ],
  "NonNodeData": {
    "Exchange": {
      "CASMailboxPlans": [
        {
          "ImapEnabled": true,
          "Identity": "ExchangeOnlineEnterprise-4aad1894-b847-4488-bb47-df02c2f2aef4"
        },
        {
          "ImapEnabled": true,
          "Identity": "ExchangeOnlineDeskless-3967a644-75e7-44fc-a644-ce517aa649b3"
        }
      ],
      "OrganizationConfig": {
        "ActivityBasedAuthenticationTimeoutEnabled": false
      }
    }
  }
}

I would like to recursively iterate through the object to do things along with merging certain properties with a similar object.
You probably want to know whether $MyObject contains HashTables (aka dictionaries) or PowerShell Objects (PSCustomObjects).
Why? because it currently matters for scripting the required iterator.
But I don't think it should be the case if the PSCustomObject type would have a few additional methods and implementations that are similar to a dictionary syntax.

Note that adding helper functions to determine the type of the (recursive) nodes and react on it could get pretty expensive for recursive cmdlets (https://github.com/orgs/PowerShell/discussions/19322).

1. As an aside, I wonder whether there is a specific name for these complex/recurse objects (as apposed to a flat object).

Proposed technical implementation details (optional)

Adding a few (hidden) methods would allow for a common iteration whether it concerns a Dictionary or a PSCustomObject:

$HashTable = @{ a = 1; b = 2 }
$PSCustomObject = [PSCustomObject]$HashTable # $PSCustomObject = $HashTable | ConvertTo-Json -Depth 9 | ConvertFrom-Json
$PSCustomObject | Add-Member -MemberType ScriptMethod -Name 'get_Count'     -Value { @($this.PSObject.Properties).get_Count() }
$PSCustomObject | Add-Member -MemberType ScriptMethod -Name 'get_Keys'      -Value { $this.PSObject.Properties.Name }
$PSCustomObject | Add-Member -MemberType ScriptMethod -Name 'get_Values'    -Value { $this.PSObject.Properties.Value }
$PSCustomObject | Add-Member -MemberType ScriptMethod -Name 'getEnumerator' -Value { $this.PSObject.Properties }

foreach ($Key in $HashTable.get_Keys()) { $Key }
foreach ($Key in $PSCustomObject.get_Keys()) { $Key }

In addition it would be helpful (if even possible) to be able to use index notation ( bracket address) for the PSCustomObject properties . Aside that this would give a common StrictMode compliant read access to the properties:

$HashTable['a'] #  returns 1
$PSCustomObject['a'] # also returns 1 (Wishful thinking)

It would imply a common and easy way to add properties to a PowerShell object (rather using Add-Member).

$HashTable['c'] = 3 # creates a new entry
$PSCustomObject['c'] = 3 # also creates a new entry/property (Wishful thinking)

---

Just another very common use case: Add a new column in CSV file by using existing columns

Wishful thinking:

Import-Csv 'C:\test.csv' | Foreach-Object {
    $CSVData['samAccountName'] = (Get-ADUser -Filter "GivenName -eq '$_.Name' -and SurName -eq '$_.Surname'").samAccountName
} | Export-Csv 'C:\output.csv

[mklement0]

Some interesting ideas, for sure.

As for your terminology question: I think object graph or nested objects would work.

Conceptually related with respect to interchangeable use of IDictionary-implementing types and [pscustomobjects]:

• Pipelining a Simple object to Get-Process is broken #13104
• Make Select-Object treat any IDictionary type's entries as properties, as it already does for a [hasthable]s #13727

[iRon7]

@mklement0,

(thanks for your thoughts)

As for your terminology question: I think object graph or nested objects would work

hmm, I am not very familiar with the word "graph" but if I translate it, or check the synonyms it feels awkward and for the word "nested", I am actually thinking of the inner objects/properties (where recursive object would describe the complete object). Anyways, I wonder whether it generally could be called a "Configuration" meaning for a Verb-Noun cmdlet name, you will get something like: Merge-Configuration (also think of Compare-Configuration as apposed to comparing flat objects with Compare-Object).

[mklement0]

I agree that nested can be ambiguous, but object graph is actually a term of art (emphasis added, though note that the linked Wikipedia article is flagged for not being encyclopedic enough - still, I think it captures the gist):

Object-oriented applications contain complex webs of interrelated objects. Objects are linked to each other by one object either owning or containing another object or holding a reference to another object. This web of objects is called an object graph

Given that such a "web" of objects isn't specific to use in configuration, my personal preference would be object graph

[iRon7]

@mklement0, @SteveL-MSFT,

I wrote this propose 1.5 years ago and since than I build a ObjectGraphTools module which was partly based on this idea that the nodes of a (complex) PS(Custom)Object could be treated similar as dictionaries and possibly even futher in means of using the square-bracket notation to access the property values (which I am not able to implement myself):

Wishful thinking:

$a = 'a'; $b = 'b'
$Json = @{ $a = 1 } | ConvertTo-Json
$Data = $Json | ConvertFrom-Json # with or without -AsHashTable ($Data -is [PSCustomObject])
$Data[$a]                        # Rather than using the hidden .PSObject.properties[$a].value to safely retrieve a dynamic property value
$Data[$b] = 2                    # Rather than using `-NotePropertyName $b -NotePropertyValue 2` to set a new property

CC: @jborean93, @IISResetMe, @iSazonov,

Sorry for involving you, but I value your opinion and I feel that this one might got buried under all the other issues and I probably didn't very well present it to get any attention. Anyways, before the microsoft-github-policy-service[bot] kicks in and pushes for a closure, I would like to have your opinion about this. Is this a feasible idea 👍 or not 👎?

[powercode]

Could you do something like this:

class ObjectGraphMethods{
    static [System.Collections.Generic.IEnumerator[System.Management.Automation.PSPropertyInfo]] GetEnumerator([PSObject]$obj) {
        return $obj.Properties.GetEnumerator()
    }

    static [string[]] Keys([PSObject]$obj) {
        return $obj.psobject.Properties.Where{$_.Name -notin 'Keys', 'Values', 'Count'}.Name
    }

    static [object[]] Values([PSObject]$obj) {
        return $obj.psobject.Properties.Where{$_.Name -notin 'Keys', 'Values', 'Count'}.Value
    }

    static [object] GetItem([PSObject]$obj, [string]$name) {
        return $obj.psobject.Properties[$name]?.Value
    }

    static [void] Count([PSObject]$obj) {
        $obj.psobject.Properties.Count
    }

    static [void] MakeObjectGraph([PSObject]$obj) {
        [ObjectGraphMethods]::AddObjectGraphType($obj)
        foreach($prop in $obj.psobject.Properties){
            $value = $prop.Value
            if ($value.psobject.ImmediateBaseOBject -is [System.Management.Automation.PSCustomObject]){
                [ObjectGraphMethods]::MakeObjectGraph($prop.Value)
            }
        }
    }

    hidden static [void] AddObjectGraphType([psobject] $obj){
        $obj.PSTypeNames.Insert(1, 'iRon7.ObjectGraph')
    }

    static [void] Initialize(){

        $objectGraphTypeData = [System.Management.Automation.Runspaces.TypeData]::new('iRon7.ObjectGraph')
        $members = @(
            [System.Management.Automation.Runspaces.CodeMethodData]::new('GetEnumerator', [ObjectGraphMethods].GetMethod('GetEnumerator')),
            [System.Management.Automation.Runspaces.CodePropertyData]::new('Keys', [ObjectGraphMethods].GetMethod('Keys')),
            [System.Management.Automation.Runspaces.CodePropertyData]::new('Values', [ObjectGraphMethods].GetMethod('Values')),
            [System.Management.Automation.Runspaces.CodeMethodData]::new('Item', [ObjectGraphMethods].GetMethod('GetItem'))
        )
        foreach($member in $members) {
            $objectGraphTypeData.Members.Add($member.Name, $member)
        }

        $customObjectTypeData = [System.Management.Automation.Runspaces.TypeData]::new('System.Management.Automation.PSCustomObject')
        $customObjectTypeData.Members.Add('MakeObjectGraph', [System.Management.Automation.Runspaces.CodeMethodData]::new('MakeObjectGraph', [ObjectGraphMethods].GetMethod('MakeObjectGraph')))

        Update-TypeData -TypeData:@($objectGraphTypeData, $customObjectTypeData)  -Force
    }
}

[ObjectGraphMethods]::Initialize()

$a = [PSCustomObject]@{
    PSTypeName = 'X'
    Name = 'Value'
    SubObject = [PSCustomObject]@{
        Name = 'SubObject'
    }
}
$a.MakeObjectGraph()

'Name:'
$a.Item('name')
'Keys:'
$a.Keys

'A:'
$a

[iRon7]

@powercode,

Could you do something like this:

Thank you for the suggestion, the ObjectGraphTools that I created is indeed doing something similar (independent of whether the nodes are of type PS(Custom)Object or dictionary , like a hashtable):

$a | Get-Node SubObject.Name -ValueOnly    
SubObject

Or using its class:

$n = [PSNode]::ParseInput($a) 
PS C:\> $n.GetChildNode('SubObject').GetChildNode('Name').Value
SubObject

to change (set) it's value:

$SubObject = $a | Get-Node SubObject.Name
$SubNode.Value = 'New sub-object value'

The goal of this propose is to get this natively into PowerShell, where I would than be able for your object-graph example to do this (wishful thinking):

$a['SubObject']['Name']                          # To get the note property value
$a['SubObject']['Name'] = 'New sub-object value' # To set the note property value

which already works for dictionaries:

$h = $a | ConvertTo-Json -Depth 9 | ConvertFrom-Json -AsHashTable
$h['SubObject']['Name']
SubObject