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.

  • This doesn't answer the question as to whether it's an answer, but you can declare a return type of an array with specified keys if you use the Psalm static analyser - see psalm.dev/docs/annotating_code/type_syntax/array_types/… . Psalm calls this an object-like array. Other static analysers may have similar features.
    – bdsl
    Aug 16, 2019 at 13:40
  • I have a hard time to understand what you mean in reliable. You consider an array object returned without the key an error or not ? Please clarify what "reliable" means for you.
    – nadir
    Aug 16, 2019 at 16:16
  • @nadir Correct. There is no way to force an object to declare a complex return type of any sorts (that is, not a scalar) so that when an unrelated object wants to work with the said object, you can always be sure it'll have an array with a key. In your implementation of that interface, you'd want to have this complex return type, but unfortunately you don't, as such, objects implementing it can only be controlled as much. You're left with doing lots of checks with if item exists in array.
    – coolpasta
    Aug 16, 2019 at 19:03
  • Could you give a bit more info? What language (I'm assuming you can't just add the feature)? Is it a case where the function CAN return a complex type but doesn't have to? Can you reliably differentiate scalars from complex types, and different complex types from each other? Can you implement returns via callbacks?
    – aerohammer
    Aug 17, 2019 at 5:57
  • 1
    @aerohammer I'm pretty sure the language in the code examples is PHP, although someMethod['key_that_every_object_should_have'] should be someMethod()['key_that_every_object_should_have'] . someMethod is returning an associative array, which is more like what other languages call a dictionary, with the key key_that_every_object_should_have.
    – bdsl
    Aug 17, 2019 at 12:58

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.