On Sat, May 22, 2010 at 6:09 PM, Zeev Suraski <z...@zend.com> wrote: > > I encourage everyone to take another look at this RFC even if you've read > it before. > > Thanks, > > Zeev > > Hi internals,
Last time Zeev wrote an RFC for type hinting, I was (as a user) all for it. This time is no different. Please let me add to my post back in october '09. The RFC introduction should have said everything, but some people seem to disregard some things. I see two kinds of API available in PHP: internals which is written in C (some with strict typing, some not), and userland which is written in PHP with no typing/checking (for the moment at least). Similarly, I see two different kinds of PHP users: those who write any kind of code used by other PHP users (let's call them API developers), and the users who write the final applications with PHP, using a combination of internals API and userland API (let's call them API consumers). I don't beleive those two groups of users have the same background knowledge or the same expectations from PHP. >From what I understand, strict type checking (or strict typing) only looks at the type of the variables, while type hinting also converts their value if necessary. Let's start by some basic understanding of what writing an API implies. As an API developer, you don't now when or how your functions are called. You simply have no say in this. You could write documentation, but there will be situations where the API consumer does not have the will, the time or any other notion that would prevent him from reading and applying good practice. Saying "just read the doc" is not enough. In some situations, your code will be wrongly used, and you can avoid disaster if you correctly validate the values passed to you. If you don't, passing the right type but the wrong value could be more problematic than passing the wrong type with the right value, which is what would happen most of the time without any kind of hinting/checking. As the API developer, you have some responsibility to make sure your code works on most cases. The API consumers count on that, because they often do not have the same understanding of the consequences as you do. That does not mean your code should work in every single case, but whenever it is expected to work (from their perspective). Here is a general case when a parameter of the wrong type is passed: With strict typing, the API tells the consumer that it is doing something wrong. Adding a cast to his code, he can go on. With type hinting as proposed by Zeev and Lukas, your code converts the variable. No need to manually cast anything, same results. Since PHP has weak types, as a consumer I can not know for sure at any time of what type each of my variables is. Therefore, with strict typing, I would have to cast each of my variables each time I used any API function. And of course, any modification made to that API would mean parsing all of my code to reflect the changes. Not only would it be very frustrating, but also very confusing for newcomers who have been told for a decade that PHP is simple to learn. I think API developers would easily cope, but API consumers would likely be driven away. Best regards, -- Guillaume Rossolini
