In this new post to his site Matthias Noback talks about a topic not normally discussed outside of languages that support it natively - duck typing.

For quite some time now the PHP community has becoming more and more professional. "More professional" in part means that we use more types in our PHP code. Though it took years to introduce more or less decent types in the programming language itself, it took some more time to really appreciate the fact that by adding parameter and return types to our code, we can verify its correctness in better ways than we could before. And although all the type checks still happen at runtime, it feels as if those type checks already happen at compile time, because our editor validates most of our code before actually running it.

[...] think that nowadays many PHP developers agree that silent type conversions is not something which is very useful, nor safe. But sometimes it's good to remember what's possible with PHP, due to it being a dynamic scripting language.

He goes on to give an example of the flexibility of PHP and how the most basic functionality usually provides the most "loose" level of abilities. He talks about type enforcement, limiting interfaces and the things PHP does natively to help keep it simpler instead. He then introduces the duck-typing-library package and what it offers to help you run validation against values to ensure they're correctness and type.

In his latest article comparing some of the functionality of PHP to Ruby, Dave Kennedy looks at modules, mixins and ducks and how they compare to PHP's interfaces and abstract classes.

If you have been writing PHP for a few years you will no doubt have come across Interfaces and Abstract classes. They were introduced in PHP5 object model and since have had medium usage in the PHP world. If you Google "PHP Interfaces" you will get some results on the official documentation and the rest saying how pointless they are. Why the divide? I believe it is mainly down to lack of understanding to what interfaces give you. They imply what your classes should do, but that’s it. Yep, we are talking programming contracts.

He starts with some code examples of an interface and a class that implements it (to work with PDFs). He makes an abstract class to extend the functionality even further and allow for different kinds of reporting PDFs to be generated. From there he moves into the Ruby world, showing examples of duck typing and modules to avoid duplication (mixins).