Are complex return types the answer to being able to depend on objects that implement said interface?

Question

Assume I have an Ingest object that will only work with objects that implemented the MyInterface interface. The ingester takes all the said objects but our language does not have complex return types, as such, these objects, when implementing the interfaces, can only be "forced" to implement basic return types. Our interface, at best, will look like this:

interface MyInterface
{
    public function someMethod: array;
}

Now, in our ingester, we might decide to loop through all of our objects:

for( $objects as $object ) {
   print $object->someMethod['key_that_every_object_should_have'];
}

...and we hit an error. Even though the return from someMethod is indeed an array, it doesn't have the key key_that_every_object_should_have and so, if we were to have complex return types, could we consider the object reliable?

What are the cases where, even with this, these objects are still not reliable?

I understand reliability is given by what you're trying to do with these objects in other places, but these objects shouldn't change their behavior just because you want to do something with them. They're as-is and they set the boundaries for the outer world.

Answer 1

If your language doesn't give you the option to return user-defined types from interfaces (which indeed improves API visibility), you shouldn't be discouraged.

As you suggested, you can "dog-tag" the dictionary object returned by specifying a specific key that should be presented in objects returned from such interface.
Since your language doesn't help you to achieve it, and you don't have strong type-checking to enforce it automatically. It's up to you as a software-engineer to achieve such thing with whatever tools you have.

You should implement a well-defined way to label such dictionary objects (for instance, by creating a specific key that label it).
It should be documented heavily and being enforced by your team members.
It may indeed create an "aspect"-constraint for your program (by running the check in run-time before using the object and err gracefully if needed).
You can try to integrate tools as suggested in the comment to make it easy. Else, try to make it DRY as possible and design your tag scheme so it can be as efficient as possible.

Of course, if the API you try to implement will be used by "outside" customers, such documentation is important for them too.