Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85413
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAJ97eO3=1YbfLAK2tY-zLpWMdr6DrkE_0nehykWA7LnQa_Cx2w@mail.gmail.com>
References: <CAJ97eO3=1YbfLAK2tY-zLpWMdr6DrkE_0nehykWA7LnQa_Cx2w@mail.gmail.com>
Date: Mon, 23 Mar 2015 03:56:07 +0900
Message-ID: <CAGa2bXaQdeRYohaqmN98DfcVF4y=CgRz1cs=Edojb2Mq4FiDEg@mail.gmail.com>
To: Nathan wesley <nathan.o.wesley@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0116066485eaaa0511e51c08
Subject: =?UTF-8?Q?Re=3A_=5BPHP=2DDEV=5D_Ten_years_estimated_Plan_to_replace_PH?=
	=?UTF-8?Q?P=E2=80=99s_inconsistent_API?=
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0116066485eaaa0511e51c08
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Nathan,

On Sat, Mar 21, 2015 at 1:01 PM, Nathan wesley <nathan.o.wesley@gmail.com>
wrote:

> I know that many people talked about this over and over.
>
> Why it=E2=80=99s not possible to change the old PHP API ?
>
>     The answer is always because it will make HUGE BC breaks
>
> I=E2=80=99ve seen this wonderful idea about scalar objects authored by ni=
kic
> github https://github.com/nikic/scalar_objects.
>
>  This will become even more possible when PHP 7 is introduced because of
> scalar types and many great features making the idea more reliable.
>
> This makes an opportunity to replace the old API with object oriented one
> preventing any kind of BC break.
>
> But instead of using this as an extension because of some limitations lik=
e
> =E2=80=9Cstring=E2=80=9D->startsWith(=E2=80=98s=E2=80=99); the API should=
 be bundled with the engine (not
> written in PHP).
>
> This will make the opportunity to also remove any inconsistencies in the
> API behavior as well.
>
> I know that many people here will say that it=E2=80=99s not that importan=
t
> developers get used to this API and many tutorials based on it.
>
>   But it=E2=80=99s actually really important for the future of the langua=
ge may be
> not so much for the existing developers (I disagree it=E2=80=99s). but th=
is will
> also encourage new comers to use PHP.
>
> I=E2=80=99ve seen many articles encouraging new comers to learn languages=
 like
> Python or Ruby, and highly discourage them from using PHP. Also many new
> projects are using languages different than PHP. (don=E2=80=99t tell me y=
ou haven=E2=80=99t
> seen this)
>
> This will be an issue the number of language users will drop significantl=
y
> over the years causing the death of the language.
>
> I know that this is not an easy task. But this is a wonderful opportunity
> to do this without BC breaks. I=E2=80=99m not suggesting that this should=
 be for
> PHP 7.0 because it will take a lot of work may be for  any release in PHP
> 7.*
>
> PHP internals around 40 people ? not really sure but I know you are very
> busy with fixing bugs and you have a lot of work already if you think thi=
s
> is a huge task it can be assigned to a good group of people similar to ho=
w
> the amazing PHP Framework Interop Group has accomplished,
>
> for Designing the new Object Oriented API. PHP internals will vote on the
> design and  implement it.
>
> The old API should be deprecated in PHP 8.0 and removed completely in PHP
> 9.0 (finally)
>
> I hope that you take this seriously and tell me if there are any
> limitations that prevents this from happening.
>

I don't think almost all of old API will not be removed.  "Replace"
wouldn't work
well as it breaks apps unnecessarily.

What we can do is "Provide new API and improve old API, while keeping
compatibility as much as possible".

Anyway, we are better to decide how PHP internal is going to use namespace
ASAP. It gives us a lot freedom for introducing new API while keeping
compatibility.
I fully agree that consistency is very important. Let's be consistent as
much as possible.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0116066485eaaa0511e51c08--