ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
Understanding what is wrong with meritocracy (part one)
Being fair is very important to me. I have however not really devoted my life to determining what the definition of fairness is, I mostly rely on my gut feeling here, like I assume most people do. In that sense I also accept that fairness, how most people apply it, is based on social conventions and personal experience. Both of which are not necessarily "just" in that social conventions often simply keep the ignorance of the past alive and personal experiences are essentially a social experiment with insufficient data. However I also assume that not leveraging social conventions or personal experience would make my daily life impossible as I would be overwhelmed with all the decision making. But if we choose to not challenge us in our daily life out of convenience, we should at least review our decision framework at regular times, especially by actively trying to expand our personal experience with the experiences of others.
The future of PHP .. at a distance
Its been quite a few years since I have been last subscribed to the internals mailing list. I still hang out in one of the popular core dev IRC channels, follow quite a few on twitter. So I still manage to stay on top of what is happening more or less but not the details in the discussions. Just wanted to put this as a disclaimer. Any opinions in this blog post are opinions formed watching something at a distance and this always runs the risk of being quite wrong or more impartial.
API versioning in the real world
We here at Liip are currently building a JSON REST API for a customer. At least initially it will only be used by 3 internal projects. One of which we are building and the 2 others are build by partner companies of the customer. Now we want to define a game plan for how to deal with BC breaks in the API. The first part of the game plan is to define what we actually consider a BC break and therefore requires a new API version. We decided to basically define that only removed fields, renamed fields or existing fields who's content has changed should be a BC break. In other words adding a new field to the response should not be considered a BC break. Furthermore changes in how results are sorted are generally not to be considered a BC break as loading more data or an upgrade of the search server can always result in minor reordering. However we would consider a change in any defaults to be an API increase (f.e. changes in default sort order) or changing the default output from "full" to "minimal" to be a BC break. But I guess we would not consider changing from "minimal" to "full" as a BC break as it would just add more fields by default. That being said, for caching reasons, we try not to work with too many such defaults anyway and rather have more requirement parameters. With these definitions ideally we should only rarely have to bump the API version. But there will be the day were we will have to none the less.
What is next for Symfony2?
Or rather what is left to do for the Symfony2 community? Obviously there are some missing features, bug fixes, performance enhancements and polish to apply to various parts of our code base. In terms of features, I think the main part that could use some more love is the HttpCache. But by and large, I think we cover everything that we need to cover and we do it quite well. When looking over the 3.0 UPGRADE file I am also not seeing of anything that hurts bad enough that would be a good reason to start working on the next major version. Given that, the question becomes where to direct our attention as a community?
__toString() or not __toString()?
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.