Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXa5zER03VrMrtD9aUQ38LK9C_UWU-jbGjzEZUoxbUsSQQ@mail.gmail.com>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@mail.gmail.com>
 <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com>
 <CAGa2bXaQ0SgLWdv7WCoo_qyOQH=t2Vi_bwpk7qXZDEUk+7S7ew@mail.gmail.com>
 <54F4F3FC.6060501@fischer.name> <CAGa2bXb-d7A3So8e76=p5qqxrZgLK2B_4RKA1OKg0nHZiw9z6A@mail.gmail.com>
 <54F4FDFB.8010701@lsces.co.uk> <CAGa2bXZUvJJVDVj-48qpPuMas12fnDigKGcE-r=TK20Sahyi7w@mail.gmail.com>
 <54F5895D.3090002@gmail.com> <CAGa2bXbuNEcvoeeBhkUUEkiHZJFvJTVX=h_JPTLHpMTtgbCokw@mail.gmail.com>
 <554F0C3F-770F-4694-A5AB-FDC54FCCBF00@gmail.com> <CAGa2bXbDdS=N=JmPwBa1iorx1aJPuo00EfU7bw31cknAxAfDyQ@mail.gmail.com>
 <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com> <CAGa2bXYrsa7t80qo_9YEiU=ZD4k+KESU3Hn+DiJeVvwgFyyjRQ@mail.gmail.com>
 <5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com> <CAGa2bXa+RyQLuYe72f2m+j5c+YObfPtaOTeknMRU7p3s+96Seg@mail.gmail.com>
 <CEF2AD42-3CE1-489F-8192-D1DC3D8D8698@gmail.com> <CAGa2bXZDnuE3mKQYD+Sq2=kH=YDXuRQA3o+9wg4v81ZS+h3rLw@mail.gmail.com>
 <54F83C4D.1020206@gmail.com> <CAEZPtU6ni038E+b0ziAC1b0w=t3gsmBwMjAui4e0sXd8EgbyXQ@mail.gmail.com>
 <CAL0xaBF7u2h9A5UnVB+-z6SwDtLOVY_qL7B9UGj7w_Lecwct6A@mail.gmail.com> <CAGa2bXa5zER03VrMrtD9aUQ38LK9C_UWU-jbGjzEZUoxbUsSQQ@mail.gmail.com>
Date: Fri, 6 Mar 2015 01:22:35 +0200
Message-ID: <CAL0xaBFJtxd3gf9H3ToD0-6mugOBFWR50wB_MRnQ0UZsPWF0Fw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Pierre Joye <pierre.php@gmail.com>, Rowan Collins <rowan.collins@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c21e3207b32c051092d921
Subject: Re: [PHP-DEV] Consistent function names
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a11c21e3207b32c051092d921
Content-Type: text/plain; charset=UTF-8

2015-03-05 22:20 GMT+02:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:

> Hi Arvids,
>
> On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks <arvids.godjuks@gmail.com>
> wrote:
>
>> 2015-03-05 13:49 GMT+02:00 Pierre Joye <pierre.php@gmail.com>:
>> >
>> >
>> > 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
>

Why not take advantage of namespaces and do the new API, building it up
version by version (sure it can't be done in one go), so probably the
extensions gonna follow too.
That allows you to use as OO interface, so do the functions. Well, yes, it
will be under a namespace, but at least new projects can be started that
way. And old code will be easy enough to port, it's mostly a question of
refactoring tools.

Aliasing is a stop-gap measure, isn't it? API's tend to get redesigned and
PHP's is due to a major makeover. So, why not embrace it? No one's forcing
to retire the old one any time soo, and I belive people understand it will
be a very long time before it is phased out, if ever (well, I think in like
20 years probably is doable). And if done right, it may be done in a way
that if you don't need it, you can leave out the old API on compile stage -
not sure if doable thought.

Arvids.

--001a11c21e3207b32c051092d921--