> On 04 03 2015, at 09:58, Lester Caine <les...@lsces.co.uk> wrote: > > 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, please stop posting walls of unrelated text. You’re totally off track. If we’re talking about coding standards, we’re not talking about PSR, but http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS <http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS> Regards, Mike
