Who did this? Who's responsible?

[exotic lichen]

PS> $hashCollision = @{ count = "2" }
PS> $hashCollision.Count
2

So I cannot trust even PowerShell now... (never could)

Now that I know it gives priority to the keys instead of properties, what should I do? Live in constant fear that one day some of my old code is gonna suddenly fail and I will be none the wiser? Or go through all of it and change all the .Count calls to intrinsic members, like .get_Count() or psbase.count (with the latter also failing in some cases)?

We're talking dynamically populated hashtables here, no control over the input data — I was lucky the value happened to be Generic.List and not just string, otherwise I would never have caught it.

So what now? Future code is no problem — lesson learned. But what about the old code?

P.S. Yes, I did read about it in the about_Hash_Tables article a long time ago, but it is just a small little note, not much attention drawn to it.

P.P.S. Personally, I think it was a bad decision to let users access the keys with dot notation instead of only allowing ["key"]. And even then it could've been avoided if priorities were set differently.

[ashen linden]

doesn't come up super often, so change the old code if you want to be extra careful, or don't and it's probably fine

[exotic lichen]

The thing is, hardcoded hashtables are really rare in the two projects I'm working on. And the probability of one of these hashtables being populated with a key named count is relatively high, giving the nature of the task.

But even if we limit it to just one of these projects, it is still 7.5k-10k lines of code that I have to go through, edit and manually verify. Will be ve-ery prone to my petty human mistakes...

So it's a balance between "preventing very possible collision in the future" and "risking creating more issues here and now".

[ashen linden]

And the probability of one of these hashtables being populated with a key named count is relatively high, giving the nature of the task.

you could be right, I don't know the nature of the task. But are you sure? It's a pretty uncommon key name

especially if it's been running for awhile without issue so far

either way though, that's entirely up to your own risk acceptance. You seem to have a good handle on the potential risk of each. The actual answer is going to depend entirely on your project

[exotic lichen]

But are you sure?
Sure as I could be, sir.

Only 74 matches out of 478k lines, but they're there all right. And they're bound to be there in any other possible input file (real one, not a sample).

[exotic lichen]

It hasn't been running, it's been heavily in development for the past month, but none of my test samples/earlier functions were prone to this issue. Only closer towards the end I was lucky to have it included in one of the input samples I ran functionality tests on (and it was the last series of tests with fully developed module — call me lucky).

This particular tool may or not be used by others and realistically, of course, I expect only myself to use it. But I'm also thinking about all the past code I've written and whether or not it is prone to the same issue...

It's a mine waiting for someone to uncover it.

[ashen linden]

this particular one needs to be fixed for sure, if you know there will definitely be a conflicting key. In general it's really not that big of a deal, just keep it in mind for the future

also fwiw I'd personally go for a psobject there. Looks more like an object than a dictionary, and this would be less ambigious as well

[exotic lichen]

Oh, the code really uses the advantages of it being a dictionary. Besides, psobject exposes its items in the same way, allowing for a dot notation to be used.

This might be a good time to ask: in general, what other potential complications one might encounter that are similar to this collision? They are usually mentioned separately on related doc pages, but I haven't yet seen them aggregated in one place.

[ashen linden]

https://github.com/nightroman/PowerShellTraps something like this?

[exotic lichen]

Oh yeah, now I remember seeing this Roman's repo! It was saved in my bookmarks when I started learning PowerShell, but then quickly forgotten.

Thanks!

[ashen linden]

as for your original mostly (I assume) rhetorical question of why:

while I agree with you that it was probably the wrong call, I get it. If you instead expect the key and get the number of entries in the hashtable, you'd be just as confused. The average PowerShell user is also (arguably) less likely to be asking for Hashtable.Count

(and as for who - probably Jim Truher. I'll ask him next time I get the chance)

[exotic lichen]

I am convinced we would've been better off only accessing properties and methods through the dot notation. Maybe not as cool, but much more reliable.
Not perfect, though: even with ["key"] you still have some corner cases when the said key is a number and you have to use casting like this: $hash[[object]$number]

Well, tell Jim I said "Hi"! I'll be living in fear for some time now...

[ashen linden]

it's one of many convenience trade offs made. It's sort of the name of the game in PowerShell. C# is much more strict if that's what you're looking for

[exotic lichen]

Of course. But I wouldn't have been writing here if I didn't like PowerShell, would I?
Besides, I intentionally chose PowerShell for some of its many benefits

[ashen linden]

yeah for sure, I just mean "it would be reliable" isn't as compelling as an argument when it comes to PowerShell features. Not that reliability isn't a goal, but it isn't the primary goal

[wise stirrup]

@{ Count = 4; Keys = @("To the sedan", "To the jeep")}.Keys
This is my favorite scary story