@heluecht We do this because we keep getting reports of missing keys in arrays and unexpected behavior where only the inspection of arbitrary arrays allows us to troubleshoot the issue. Introducing coding rigidity does have a cost in terms of raw performance, but then again we code in PHP, so we aren't gunning for pure performance, are we?

And yes, I understand the annoyance to have to add new concepts to thwarts the limitations of the new concepts, etc... but it has to be compared with the whack-a-mole game of finding out when and where an arbitrary array got its wrong/missing value. In a system that processes asynchronous requests like a federated one, I believe it would pay off if we could abstract remote systems to test our code instead of having to send ourselves some message from an actual remote server and then anxiously poring over the log to spot the var_dump() call output we had to add on a production node.

If it doesn't bother you, more power to you but I'd like to prepare the project for a time you won't be around anymore. In its current shape, I believe the project development would grind to a halt if you stopped contributing for any reason, because you (and only you) have readily done this kind of debugging in the wild to fix the protocol/federation aspects.

We're still light-years away from the complexity of the Symfony or Laravel PHP frameworks and my goal isn't to get anywhere near either of them. We also could use a third-party Object-Relational Mapping library like Doctrine to outsource the tedious task of finding out the inefficiencies of hydrating typed object from a database and fixing them one at a time.