Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85425
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <550F1B2C.9070607@gmail.com>
References: <CAJ97eO3=1YbfLAK2tY-zLpWMdr6DrkE_0nehykWA7LnQa_Cx2w@mail.gmail.com>
	<550F1B2C.9070607@gmail.com>
Date: Mon, 23 Mar 2015 22:47:17 +0300
Message-ID: <CAJ97eO2eyca8Pz3h5Dq6Pzx3R6KFjY9nA5BGn8o1XWHZTmAg4g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ce09a0284300511f9ef2d
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: nathan.o.wesley@gmail.com (Nathan wesley)

--001a113ce09a0284300511f9ef2d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> Hi!
>
> > This makes an opportunity to replace the old API with object oriented o=
ne
> > preventing any kind of BC break.
> >
> > But instead of using this as an extension because of some limitations
> like
> > =E2=80=9Cstring=E2=80=9D->startsWith(=E2=80=98s=E2=80=99); the API shou=
ld be bundled with the engine (not
> > written in PHP).
>
> This is the problem with all these proposals. Instead of taking the
> gradual road of making a beautiful API in extension, having it accepted
> (I'm taking the optimistic scenario), popular and then merged into the
> engine, it's always "let's redo the whole engine from scratch". That's
> why these things haven't gone beyond talk for years.
>

I didn't say that you should redo the whole engine from scratch this is not
possible of course taking the FIRST step would be great
when i talked about 'extension' i mentioned the limitations. but i meant
the API shouldn't be written in user land code that's all
it can start as an extension and gradually support these limitations when
more people start to use it.


>
> > This will make the opportunity to also remove any inconsistencies in th=
e
> > API behavior as well.
>
> You write "remove inconsistencies", I read "break all existing code".
>

you didn't get my point. i mean't the new API shouldn't behave the same as
the old one there are some behavioural inconsistencies shouldn't be
introduced in the new one. the old API won't be touched at all. no breaking
for existing code. that's the point of this proposal


> > I=E2=80=99ve seen many articles encouraging new comers to learn languag=
es like
> > Python or Ruby, and highly discourage them from using PHP. Also many ne=
w
> > projects are using languages different than PHP. (don=E2=80=99t tell me=
 you
> haven=E2=80=99t
> > seen this)
>
> I've seen a lot of silly stuff on the Internet, so what? It's a free
> medium, anyone can write anything. That doesn't mean it carries any
> weight by the fact of writing.
>

When the vast majority agree that's a problem (it carries weight). it's
just too common.
famous articles written about it like "PHP fractal of bad design" and "php
sadness" a lot more
i highly doubt that you didn't read one of these.

i like PHP i care about it. it's future is important you "the internals"
will decide what will happen
many years from now. and you have a good opportunity to get this right.
even if someone managed to
do all of these things and submit an RFC you will vote on it. only you can
decide i hope you chose the
right thing.


>
> > The old API should be deprecated in PHP 8.0 and removed completely in P=
HP
> > 9.0 (finally)
>
> Which means no code written in PHP would work in PHP 9.0. Why then call
> it PHP? Call it something else.
>


You just agreed on disagreeing :) this is 20 years until PHP 9 comes out.
PHP 7 is not yet released. you can
argue about it when we get to this point in time. maybe the need for
removal can be predicted by the adoption of the new API. the old mysql
extension was also used everywhere.


> BTW, if you look at Java, some methods deprecated in Java 2 are still
> around in Java 8. Java didn't die from it. Why people are so zealous to
> break things that work?
>

i didn't mention any break or things. also many languages are different
from they were 20 years from now. languages keep evolving. you may not see
this as a breaking change 20 years from now imo


Thanks for taking the time replying to this

Regards

--001a113ce09a0284300511f9ef2d--