[asddubs]

Took me a really long time to learn this lesson. IMO this is a variation of the primitive obsession code smell, although I'd say it's way more harmful. I was really reluctant to add data classes to my code when the good old PHP array could get the job done without holding me up with a bunch of beaurocracy. Of course they give no guarantees and enforce no structure, so inevitably you get slight variations depending on what you need, or maybe you happen to have a dict that's a superset of what you're feeding in, and it just becomes really hard to reason about things. And of course since it's not a named type, tracing things back becomes really hard.

[Supermancho]

> so inevitably you get slight variations depending on what you need

If you have a generic collection, you know it's generic. It does remove a class of errors when you start adding types, but it also adds problems in making changes as a tradeoff. Now I have to make a PR that is the change I want AND I have to modify the type, which comes with explaining/understanding that there isn't a reason to use 2 different types or what the consequences would be to create a second generic collection from the first and modify THAT instead (eg lists with different types, how big are they?).

Never was a big problem using generic collections over the last 30 years and plenty of languages are fine without the training wheels of defining every data structure as a type, so I'm not sure what this ranting is all about.

[asddubs]

I'm not sure if I'm misunderstanding your point or you're understanding mine, so I'll just carefully say that the PHP array is really a dictionary + array combination type, and I was referring specifically to its use as a dictionary (since that's what TFA is about). If you're returning a list of things that are all the same type I agree that an array, or an array of a certain type if generics are available is totally fine and serviceable.

but if you're passing in/out some monstrosity which has a structure that you can only really find out by reading the code, often from top to bottom if different parts of the dictionary are referenced in different parts of the code, you are really setting yourself up for trouble down the line.

[Supermancho]

> if you're passing in/out some monstrosity which has a structure that you can only really find out by reading the code

This is conflating multiple issues. Using generic collections (dictionaries, if you like) and then trying to work out what's in them. Modern stacks include a debugger, so figuring out what's in them is trivial in a given code path, if you have a test environment.

Figuring out how to use them (or how to not abuse them) when you have an immature development environment, is the issue at hand.

The author of the blog implies that they will necessarily be problematic. That's incorrect on it's face, but let's get into a codebase where we have no frame of reference, documentation, a limited dev environment, and/or the tests are missing/ignore the ramifications of the dictionary containing a variety. The question then becomes one of ascribing blame in these conversations:

1. is it the fault of the original programmer in selecting a dictionary? - No

2. is it the natural outcome of using a dictionary? - No

3. is there a compelling reason to use a dictionary at all (over a typed list)? - Yes and I would say more than one.

That's all aside to the issue of "what do you do now?" Well you do research and work, same as any of these tangled codebases (which may not be tangled at all). You break it up, you write tests and then you reason about the choices made. None of this is particularly special in regards to dictionaries. It's a particular practice that is sometimes expedient or efficient and that seems to offend the author's sensibilities. It's zealotry.

[BurningFrog]

Whenever you use the same string key in different parts of the code, you take one more step on the Legacy Code Road...

I still walk that road sometimes, but not for very long.

[klyrs]

Who needs hashes when you've got variable variables? ~ me, 20 years ago, learning the hard way

[andreareina]

I still don't know how I feel about the fact that in PHP $$var (a) works, and (b) does exactly what you'd expect.

[klyrs]

Early days of PHP were total madness. GET vars initialized variables in the global namespace. Uninitialized variables treated as zero/empty string. People were rolling their own query sanitizers in the best case. Misconfigured servers often horked out script sources. Why not pour some gas on it with variable variables?

[b3morales]

This level of introspection can be useful in some cases. Perhaps the flaw is just in giving it such simple, attractive syntax.

[klyrs]

I think so. You can get at the __globals__ dict in python to similar effect, and I've rarely seen that abused.