On 04/03/15 03:34, Yasuo Ohgaki wrote: > I made list of rename candidates > https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed > If you have suggestions, I appreciate!
Taking the starting point ... the coding standard for writing C code for PHP ... personally I would love if the PHP code area followed all of the rules in the C set. My own particular grip is with using tabs internally in the C code, but spaces in the PHP code. The very reason that PSR is another inconsistency. So we follow C rules for C code and PSR rules for PHP. Or not ... I will always use tabs across all code bases, but the other point here is that PSR demands camelCase rather than adding underscores and many of the new libraries have been added following that format rather than the C rules. So even replacing the whole structure of internal names, they will be inconsistent with external naming 'rules'. The coding standards themselves are inconsistent :( If we are looking at the C codespace, then as has already been said we are using C library names in a large majority of cases. So programmers who are switching between C and PHP codespace either need to rebuild all of the C libraries using the new names, or live with that inconsistency? I am slowly coming around to the thought that since how I would prefer to work is not going to be provided by PHP then creating my own versions of some extensions is going to be the right way forward, so I will perhaps be working more in 'C' space than in 'PHP' space. This is partly because of the growing uncertainty about handling SQL compliant types in PHP, and the increasing need to work out how to add back the limit checks provided naturally by 32bit processor builds. There are a lot more important things than introducing what I view as yet another layer of inconsistency when for example, the whole string management area needs to be augmented with a proper object based structure where the str_ becomes redundant? mbstring should also become redundant in that rework. As I have already said, the GD library is just a wrapper around the underlying libgd C package, and while it is now maintained by Pierre under the umbrella of PHP, it is used in other languages so creating a new wrapper for PHP without regard for it's C and other interfaces is again introducing more inconsistencies. While http has been rejected for bundling, it is another example of not following the C coding standard ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
