On 3 March 2015 18:54:56 GMT, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >Hi Rowan, > >On Tue, Mar 3, 2015 at 7:13 PM, Rowan Collins <rowan.coll...@gmail.com> >wrote: > >> Yasuo Ohgaki wrote on 03/03/2015 04:01: >> >>> Hi Lester, >>> >>> On Tue, Mar 3, 2015 at 9:19 AM, Lester Caine <les...@lsces.co.uk> >wrote: >>> >>> On 02/03/15 23:54, Yasuo Ohgaki wrote: >>>> >>>>> This looks awful... just cannot put up with... >>>>> >>>> Rasmus has already answered, but are you prposing to rewrite -> >>>> http://www.gnu.org/software/gettext/manual/gettext.html >>>> >>> >>> I know we used to have had copy of C library names. >>> I already explained why it looks awful. It violates coding standard >and >>> sitting in PHP for more than a decade as it is. >>> >> >> You keep mentioning this coding standard like it's the Holy Bible. >Coding >> standards are only as useful as the problem they're trying to solve, >and >> there can always be justified exceptions to the rule. >> >> I doubt most PHP users look at that list of functions and think "tsk, >tsk, >> the PHP devs didn't follow their own coding standards". They might >think >> "why are these functions named the way they are?", in which case >Rasmus has >> provided the answer, in terms of "vertical consistency" with >cross-language >> libraries. >> > >First of all, I'm not blaming anyone who named functions that violates >coding standard. >It was ok name them like this. I would name after under laying library >functions also. > >If the cost of having consistent name is too high (too much >cpu/mem/etc) ,
You are measuring the wrong cost. The cost of adding new names is to people writing code: - additional confusion for new users about why everything has two names and which they should use - extra effort for new developers to learn the new names, even if they only read them in other people's code (it slows me down every time I see sizeof() and have to remember it's just an alias of count()) - awkward decision for project leaders: use the old names for familiarity and compatibility with older versions, or the new ones because they're arguably better names - if an existing project does choose the new names, the overhead of converting all the existing code, with the risk of bugs introduced by incorrect automation, noise in commit logs, merge conflicts, etc - if a project needs to run on PHP 5, the vigilance required to avoid accidentally using the new names when developing on PHP 7 That's not an exhaustive list, and some of these aren't huge costs, but collectively they outweigh the benefit of a slightly more consistent set of names for things. This is why a more radical change - an OO-style API for scalars and basic modules, a fundamentally new set of functions which fulfil a specific need, etc - has the potential for acceptance, and this proposal does not. The costs are mostly fixed, so we need to increase the benefits to outweigh them. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
