Tag: complex

The more I write OOP, the more I realize that besides reasoning & structure, there isn’t much for me and things make more sense if I combine that with functional or just straight-up non-OOP. Not over-engineering is truly a blessing when working with large code-bases and in that case, your #1 goal should be to create clear & reliable code. My issue ties to both of these traits.

Assume I had an IngestedInterface which objects I’m working with need to implement so that my system can understand them:

interface IngestedInterface
{
    public function getData() : string;
}

Then, assume I had an ingester object A who worked with IngestedInterface B objects’ getData:

class Ingester
{
    public function __construct( IngestedInterface $ingested )
    {
        $this->ingested = $ingested;
    }

    public function doSomething()
    {
        $data = $this->ingested->getData();
    }
}

We can be 100% sure that $data is a string. But the situation gets muddy when dealing with PHP’s most popular feature: arrays. Assume my doSomething changed to:

public function doSomething()
{
    $data = $this->ingested->getData();

    return ( $data('some_key_1'), $data('some_key_2') );
}

We implicitly rely on some_key_12 being returned from getData and depending on what you do with them, that they’re of a certain type as well. If they’re not, the script crashes since it’s looking for a key it cannot find and we’ve just created unreliable, unpredictable code.

There should be a newer, improved interface type that supports complex return types such that expressing a minimally viable (meaning you need these at the very least, but can add on top) array structure to return is possible:

interface IngestedInterface
{
    public function getData() : ('some_key_1' => <int|string>, 'some_key_2' => <string>)
}

This way, it naturally tells whoever wishes to build upon this IngestedInterface that they need to have a complex return for getData. I perfectly understand that I can just have 2 functions for each one of these and just use simple return types, but it makes absolutely 0 sense to separate two things (some_key12) that are closely related to each other and this case is very common. This is not what I’m looking for here.

Why do I want this? Because I don’t wanna write an array_key_exists and an is_%scalar_type% for each god-damn possible kv pair inside an array, in fact, ensuring that an array I’m working with has the right structure oftentimes implies even more checks, all of which could be easily solved with a complex return type.

So, what am I missing? Is this not a desired feature? It’d be a game-changer for me. I write extremely sensitive code that I, unfortunately, have to interface to WordPress infrastructure which runs on PHP and every time and API/endpoint is written, I want to shed a tear since I know that if a client’s developer who uses our API feeds the wrong thing, they’ll break a lot of things if these checks weren’t in place, it’s like it gets sour even before I start writing code knowing that I’ll have to write these checks for mission-critical endpoints. In other words, can I just write code that’s resistant to such bul**** by default instead of spending my time doing data validation and why don’t we have this already?

I don’t think anyone capable of directing the core development of a language is stupid, but I can’t seem to come up with an argument against this.