Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yep. Love powershell, disliked this decision, but now understand it: objects returned from native powershell commands have a loooooooooooooooooooot of nesting. Try:

  gci | select -first 1 | ConvertTo-Json -Depth 2
  gci | select -first 1 | ConvertTo-Json -Depth 3
  gci | select -first 1 | ConvertTo-Json -Depth 4
one at a time.


In the words of Raymond Chen, adding a `-Depth` parameter is using a global solution to a local problem. If certain types should not be serialized beyond a certain depth, the config should be per type, not on the whole serialization.

Or leave it as it is and expect the user to map the complex values into hashtables. Eg in your example, make the user pipe the objects through `%{ @{ Name = $_.Name; Mode = $_.Mode; } }` first.

In any case, I don't know about other PS users, but all my command-lines that ended with ConvertTo-Json either started with ConvertFrom-Json (transforming an existing JSON file), or started with HashTables (building a JSON file from scratch) or a mix of the two. Therefore I always wanted everything to be serialized, and the `-Depth` parameter was always a nuisance.


Thankfully it looks like -Depth is going to default to 64 when the cmdlet is ported to System.Text.Json, per voxic11 downthread: https://github.com/PowerShell/PowerShell/pull/11198


True, but isn't it a good idea to have an "upper limit" global value too in case of badly behaved types?


Why? Both JSON strings and their deserialized value's memory usage grows only linearly if you nest stuff (unless you're doing something dumb).

By that logic they should also add -MaxArrayLength to make the parser stop parsing long JSON arrays, -MaxProperties to make it only parse object properties up to a limit, -MaxStringLength to only make it parser strings up to a certain length...

It's completely pointless.


I suppose it is only a concern during serialization, not deserialization.


Yes, a limit per type. Not for the whole serialization.


But what if a type which you need to serialize wrongly doesn't set the limit?

EDIT: I see your point now, thank you for explaining


Again, I'm not saying there shouldn't be a default limit. I'm saying the limit should be per type, not for the whole serialization.

It can be something as trivial as "PSHashTable is allowed to serialize without limit. Every other type is limited to N levels, unless the user sets `$SERIALIZATION_LIMIT[System.Type]` to some other value." Or make the `-Depth` parameter a `Dictionary<System.Type, int>`.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: