Hacker News Reader

Comment by nu11ptr | Hacker News Reader

Powershell wasn't awful when I wrote it but I never understood why arrays of length 1 removed the array and become the contained type. This caused a huge # of bugs as you suddenly had to care how many items could potentially be in the array and check each time you modified vs. handling them generically. Does anyone know WHY they did this?

View on HN

There's looseness around arrays because the API for emitting outputs from commandlets is also loose around arrays. There is just one function `WriteObject` that writes the value you give it as the output of your commandlet. If you call it once, then that's your output. If you call it multiple times, then the shell has no choice but to then make your output an array of all the values you write.

So if one invocation of your commandlet only calls `WriteObject` once and the other calls it twice, the shell in the first case doesn't have the knowledge that it should've wrapped that one output in an array too. And it can't always wrap commandlet outputs in arrays because that would be disruptive for commandlets that semantically only have one result and so always write only one output (like `Get-Date`).

And for whatever reason, they didn't want to complicate the API to let commandlets themselves be able to express whether they'll semantically write only one output or multiple, regardless of how many times they actually call `WriteObject`. Such an API can't be a static attribute on the commandlet because commandlets can have wildly varying output based on their parameters. It can't be an overload of `WriteObject` like `(Object, bool iMightWriteMoreValues)` because it has to work for empty arrays. So it would have to be a separate `IWillWriteMultipleValues()` function probably.

Edit: Also explained here: https://news.ycombinator.com/item?id=40874873

This is so annoying. I’ve started using the preceding comma hack to force an array.

  $Ary = @(, "value")

One cool feature for creating arrays (especially larger arrays, for performance improvements over using +=) is to assign your array to a for loop. It wasn’t an obvious method of populating an array to me, but is definitely handy.

  $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }

I think @("value") is enough.

I use

    [array]$Ary = "value"

I haven't used PS in many years, but I do remember `@("value")` would still end up unwrapping the single-element array back into its element in some situations, and the only sure-fire way to get an array was `, "value"` or `@(, "value")`

> Does anyone know WHY they did this?

That sounds like a classic case of software trying to be "too clever," nine times out of ten of which will invariably backfire.

As a software developer, one should always resist the temptation to make their software "too clever."

Agreed. This drives me crazy. You have to work around it in a script of any complexity. It's probably my least favourite thing about PowerShell.

It feels like a half baked feature. The other (missing) half would be automatically converting a single value into an array of length 1 when the receiving end expects an array.

Niche languages seem to end up with insane quirks like this every time. It's like the tragedy of sisyphus that things like lua exist, but instead of using it directly or modifying it slightly, then having a dead simple, tight, small, elegant, consistent language, people reinvent the wheel and never make it round.

Lua is not perfect either. Having a specific keyword to make variables local was a mistake. Variables should be local by default. Oh, and 1-indexed arrays are annoying.

Both of these could be changed trivially. Someone familiar with lua could do both in one day as opposed to making an entire brand new language from scratch.

This is reminiscent of MATLAB where there is no distinction between a scalar and a 1x1 matrix.

A scalar _is_ a 1*1 matrix

A scalar however is not a tuple of length 1

Reply on news.ycombinator.com