This is a perfect example what I don’t like about ORM implementations because they only pretend to do object relational mapping. In my opinion ORM’s goal is to allow the developer to work with data represented as objects not relations. And what you are doing here is simply constructing an SQL query with query builder’s methods. It is conceptually equivalent to string concatenation with the added benefit of database independence - to some extent. With an ORM I am supposed to work with objects and here we are back to SQL construction and we have to write selects and joins?
Imagine now that we replace the underlying relational database with a no-SQL database or with a real Object Oriented Database - how will this query construction work then? Join becomes a foreign concept and everything falls apart. The ironic thing is that if an ORM interface were to be used with an OODBMS then, for the most part, the ORM should be transparent because OODBMS is queried with objects natively so there’s nothing really for the ORM to do. But what would happen here? The ORM would have to map these selects and joins back to objects and methods to be able to communicate with an OODBMS!
What I’m getting at is that real ORM system does not yet exist for PHP and if it did I image it would be much more complicated than Doctrine or whatever exists now. Of course, once the query results are hydrated into objects then we get the proper object oriented data to work with. But at this stage it’s impossible to get away from SQL even if we use ORM - unless we settle for the simplest CRUD.