2017-03-24 You should break compatibility if the status quo is structurally bad and if there is a much better choice possible. You should not break compatibility without good reason. Therefore one needs to have a good understanding of the world around to know about com- patibility relations. Here I mean compatibility not only on the code level but also on the mind level. I came across mysqli's bind_param() method in PHP. Understanding it is easy if you relate it to printf(). And in fact, it's stru- turally the same: You have a string of type specifiers and a list of variables to be linked to the types. Thus, the mind compati- bility comes to play. Now the implementers of bind_param() decided to use `s' for `string', `i' for integer and `d' for ... `double'. printf(), in contrast, uses `d' and `i' for decimals (i.e. in- tegers) and `f' for floats/doubles. (PHP's printf() does not recognize `i', but Unix' printf() does so as an alias to `d'.) It was a bad decision to use `d' for `double' instead of using `f'. `i' might seem to be more logical than `d' for integers, but in the Unix context `d' (for decimal) was used because in- tegers can also be displayed in in octal (`o') or hexadecimal form (`x'). In the end, we've been driven to the same situation we have with the different types of regular expressions that exist: We have to learn each of them. Yes, they all make some sense and have their reasons, but they consume programmer's memory. This waste is so unnecessary in the bind_param() case! Why did they not just stick to `s', `d' and `f', as already known from printf()? We should have designers paying the costs for their bad design decision. But it's the programmers that have to pay, for the missing knowledge and wisdom of the designers. http://marmaro.de/lue/ markus schnalke