Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84352 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 94279 invoked from network); 5 Mar 2015 20:21:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Mar 2015 20:21:31 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.216.173 mail-qc0-f173.google.com Received: from [209.85.216.173] ([209.85.216.173:44045] helo=mail-qc0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1C/39-40418-ACAB8F45 for ; Thu, 05 Mar 2015 15:21:30 -0500 Received: by qcxn11 with SMTP id n11so17457538qcx.11 for ; Thu, 05 Mar 2015 12:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=mn+nbBveVxXSIRa6q7X+Cc6MyarUJngsyq/EQQhNWaA=; b=FY/6GghSVpgABMgnajBMM/NwJprCbPULcDyC45WpNZ7KsJiJNR3PfPSRZtHDXHpXjv mbLGc5WWSm74Bn5F1nI/jcfXOumwRpRB2QSQayCpVDa4tQPJ3hMAWfYSuPtxNImc5V7O COlD3misQ7mOoIAnX0Qj752G8RXLxUuls5U4HgANqNGm3tsR5fTScL0Glf+H8UJ64muv 8Q5Tq9QI29p8fWYUZmSMhON+lSveC6cHjvnJB5ZoQEsz+q8N50iARqA00DqmS0wC33VM 0euF+lmTgaU3dQzW6QQuZNhD8q5rBl7sQNTgSyKQI6IR6wZydmZkX8ZcK7P63gD+BdMd vi4Q== X-Received: by 10.140.201.8 with SMTP id w8mr15541666qha.51.1425586887010; Thu, 05 Mar 2015 12:21:27 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.198.8 with HTTP; Thu, 5 Mar 2015 12:20:45 -0800 (PST) In-Reply-To: References: <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com> <54F4F3FC.6060501@fischer.name> <54F4FDFB.8010701@lsces.co.uk> <54F5895D.3090002@gmail.com> <554F0C3F-770F-4694-A5AB-FDC54FCCBF00@gmail.com> <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com> <5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com> <54F83C4D.1020206@gmail.com> Date: Fri, 6 Mar 2015 05:20:45 +0900 X-Google-Sender-Auth: JkDIh0mDcqxdIqVzRO6AQ2XrhNg Message-ID: To: Arvids Godjuks Cc: Pierre Joye , Rowan Collins , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a11432238ff30620510904fbc Subject: Re: [PHP-DEV] Consistent function names From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11432238ff30620510904fbc Content-Type: text/plain; charset=UTF-8 Hi Arvids, On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks wrote: > 2015-03-05 13:49 GMT+02:00 Pierre Joye : > > > > > > I will say it again a last time, in my opinion only a clean API; > > object-like or real object as long as performance is not affected is > > the only way I could see to actually solve this problem. > > > > Changing the names, argument order (pointless once we will have named > > arguments, btw) and similar solutions are band aids solutions, > > confusing at best, terrible at worst. It is pointless to do it after > > almost two decades for some of them. > > > > -- > > Pierre > > > > I'm with Pierre here. > Adding aliases is gonna mess up things even more. For example - > autocomplete will become hard to navigate. It's already quite lengthy list > a lot of the times and it's easier just to write the whole function name > sometimes by hand. Adding aliases will make it worse. > I agree. Therefore, I'm going to update manual also so that it recommends main function, not aliases. Aliases should be alternative. Manual and IDE don't have to list all of them. New manual lists only main functions, does not have dedicated pages for aliases but aliases are mentioned in main function page as aliases. > > We really need a new API, that is not crossing paths with the old. That way > people can start building stuff on new API's and we could phase out the old > mess, for example: depricate in PHP8, remove in PHP9. > Stop-gap measures have created enough problems already, or did everyone > suddenly got an amnesia and forgot all the past lessons on the list? PHP should be multi paradigm language, not pure OO language. IMO. Python does good job. "Python is a multi-paradigm programming language: object-oriented programming and structured programming are fully supported, and there are a number of language features which support functional programming and aspect-oriented programming" http://en.wikipedia.org/wiki/Python_%28programming_language%29 It sounds like there are people who would like to discard procedural APIs. PHP has born as procedural language. It will not happen in short term at least. We are far from having rich and good enough OO APIs sets to make PHP a pure OO languages. This leads to conclusion that we need to maintain/improve procedural APIs even if we are going to make PHP a pure OO language. I finally understand why some of us against this change and suggest OO APIs as alternative. It's reasonable making procedural APIs a legacy/unmaintained/ messed up to discard procedural APIs someday. I'm against it. PHP should be like Python in this regard. IMO. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a11432238ff30620510904fbc--