The __toString() belongs to the family of methods and functions called "magic functions". They are magic because for the most part they do not get called explicitly but rather intercept operations. Unfortunately there are limits to its magic, specifically the only "context" the method is aware of is its design contract: to return a string. But its not clear what purpose that is. Should this be for some internal debugging or logging purposes? There one would be most interested in internal identifiers and object state. Is it for some frontend UI where the user will most likely be interested in some textual identifier that isn't too long as to not clutter the UI. There in lies the dilemma in the magic, while useful there is no way to ensure that the given context is passed on.

In the PHPCR implementation using Doctrine DBAL we support search queries by converting the SQL2/QOM statements into XPath queries that we run on the XML stored in an RDBMS. Sounds insane, yes .. but it works pretty well .. obviously will not scale very well .. but it works for smaller data sets and there will be ways to improve performance later. In terms of functionality we have everything working quite well including JOIN support that was added recently.

I think we already have quite a nice toolchain for REST in Symfony2 with Bundles like FOSRestBundle, JMSSerializerBundle, NelmioApiDocBundle, FSCHateoasBundle and HautelookTemplatedUriBundle. What is great about these Bundles is that they are all nicely integrated with each other. But there are still some limitations which should be addressed. The following is not an exhaustive unordered list and also not detailed enough but just something to illustrate where I feel there is still work left:

Symfony 1.x I would put into a category of frameworks focused on RAD, aka rapid application development. There are many other frameworks I would put into this category like CakePHP, Yii, CodeIgniter. All of these frameworks have their roots in the pre 5.3 days of PHP. I say this mostly because there has been a considerable shift in development methodology since then towards more decoupling and application of design patterns. As such these older RAD frameworks to me cut corners to be able to focus on the use cases they wanted to focus on. Now this is a quite legitimate approach, we all know that in order to make a solution truly generic it takes a considerable increase in effort and complexity. So focusing on 80% of what web developers need to do on a daily basis makes sense. This is mostly achieved by providing either base classes or the ability to use configuration files and conventions to reduce the amount of code needed to achieve functionality. However these frameworks tend to become quite painful when dealing with those other 20%. At that point they can actually become a hinderance and so you start to loose some of the benefits you gained for the 80% you worked on before. With Symfony2 we took a different approach. I would not call it a rapid application development framework. All it really does is add some more high level abstractions but it stays short of providing an out of the box solution. You still need to write the code and that code tend to be very explicit.

Symfony2 is without a doubt a very lively open source project. No small part thanks to Github, there is a flurry of tickets and more importantly pull requests coming in daily with dozens merged every week. These changes cover everything from small typos, to bigger refactorings, new test cases, documentation, performance optimizations. What even more positively stunning is that while there are a bunch of "usual suspects" the bulk of all of this comes from people that just submit the occasional change. Which means we have managed to make the community very inviting for new contributors. Something many other open source projects struggle with. So in a way one could say all is well. However I think its also important to define a direction for a project as a whole. I guess at a high level we are fine there too. We rarely have fundamental issues with determining what should go into Symfony2 and what should not. But what I feel is severely lacking is a prioritization and focus what should be happening within the next few months.