PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

Red tape and the art of ripping through it

Note: This article was originally published at Planet PHP on 19 July 2010.
Planet PHP

It seems like the Symfony2 CS is forbidding the use of private methods. I think other frameworks have similar rules. Now I have argued along those lines myself in the past. But especially talking to the Doctrine2 dev's got me to reconsider .. a bit. This all kinda of reminds me about the discussion over making it a fatal error to change method signatures during inheritance. I love PHP for allowing me to do this, yet giving me an E_STRICT, aka red tape, to make sure I am aware of the kittens that are being strung up this very moment. When I have coded myself into a corner, I need to get out of it quick, I do not need

I still do not believe in private, but I do believe that it would be a good idea to keep the user in the loop what the extension points are that you designed and where you commit to maintaining BC and where you don't. In many cases users may want to change a private method simply because they didn't understand the design of the API (often because they are too lazy to read the docs to learn how to do things right). Without some indication which methods are public, protected and private users would not know that they are over stepping red tape and get upset if methods are changed later on. So again I think it would be awesome to just get a slap on the wrist, aka an E_STRICT, when violating visibility rules. Since this is not the case, I actually kind of like the CakePHP approach using single/double underscore's for visibility constraints.

Now I should explain a few more things about the benefits doing the right thingA and the reasons for still sometimes not doing the right thingA. In general if an API is well designed use of private can make total sense. Basically you are saying this part of the code is not extensible, it hasn't been designed as such. Such a great designed API should however have more sensible extension points to still get the results you want. Similarly, breaking the "is a" relationship by screwing with the signature of methods will eventually bite you in the ass too, because suddenly assumptions about what you can do with an object because it is an "instance of" something will blow up in your face. Doing the right thing is the right thing most of the time.

However the reality of project life is that some times you need to shot from the hip to get things done in time and on budget. Sometimes this might code you into a corner, but it will still be good enough for the project to be a success. Again this is why I appreciate the red tape, that way I cannot accidentally do the wrong thingA, it will have to be a conscious decision and one that I cannot easily hide from the client (if they have any knowledge of PHP). I do not want to hide anything from the client, I want them to be aware of the compromises I make. But if their time and budget does not allow for a perfectly thought out design or when a time saving library simply doesn't allow me to do the things I need to do for a client, then I want to be able to overstep the red tape, because it is the best thing to do for my client. There might be clients that rather want to spend the time, and I very much welcome these kinds of clients. But I fear most of these clients rather go to a Java shop for that kind of work and they are willing to accept the additional required development time and budget requirements.

I also want to present another angle. The internet thrives on the idea of innovation at the edges. People put out things and others pick them up, twist and turn them until they do things never imagined possible by the original people. More importantly things move way faster than the original people ever anticipated and chances are good that they will have a hard time keeping up with their users. Having to wait for some upstream project to integrate some patch, or even just agreeing that a change is necessary is often just not possible in the context of a client project. Of course DVCS like git have made all of this more possible: You simply fork on the spot, easily keep up with upstream changes and when things slow down, you can contribute the changes back. But what happens if they never accept your changes or add the feature in an incompatible way? Then you are stuck with maintaining your fork, which will become am increasing pain if they make BC breaking changes upstream, just like if you might see BC breaks if you rely on extending private methods (assuming the language would allow it). So I much prefer if I could have some nagging E_STRICT remind me of the places where I over stepped the red tape.

Now knowing when it is ok to overstep the red tape, know

Truncated by Planet PHP, read more at the original (another 581 bytes)