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) , I would not propose to add standard confirming names. What I'm proposing is "How about maintain legacy APIs to keep up with coding standard and have consistent names?" More or less, we do need maintenance, otherwise phpversion() will remain inconsistent forever. IMO. I fully understand your arguments/reasoning, but I fails to see why not having aliases to have shiny procedural APIs for major version up... Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
