# PHP6 thoughts about Engine changes

- Thread: https://externals.io/message/72922
- Original archive: https://news-web.php.net/php.internals/72922
- Started by Julien Pauli on 2014-03-05T13:56:40+00:00
- Messages: 9
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #72922 — Julien Pauli — 2014-03-05T13:56:40+00:00

URL: https://externals.io/message/72922#72922

Hey,

I wrote a wiki page about my thoughts for engine BC breaking changes
in the next PHP5++ (PHP6 ?)

As usual, those are actually just thoughts.
Anyone may (should ?) improve the wiki page (keeping a readable
structure) sharing his own knowledge and thoughts :-)

Any debate for any (relevant) subject can start here.

I think that PHP5.6 final release is a good starting point for first
milestones and first ideas throught code.

https://wiki.php.net/ideas/php6/engine

Julien.Pauli

---

## #72925 — Rasmus Lerdorf — 2014-03-05T17:39:52+00:00

URL: https://externals.io/message/72922#72925 · In reply to: #72922

> Hey,
> 
> I wrote a wiki page about my thoughts for engine BC breaking changes
> in the next PHP5++ (PHP6 ?)
> 
> As usual, those are actually just thoughts.
> Anyone may (should ?) improve the wiki page (keeping a readable
> structure) sharing his own knowledge and thoughts :-)
> 
> Any debate for any (relevant) subject can start here.
> 
> I think that PHP5.6 final release is a good starting point for first
> milestones and first ideas throught code.
> 
> https://wiki.php.net/ideas/php6/engine

That sounds more like a PHP7 wishlist. Unless you have a team of
dedicated programmers lined up to work on this, that list will take us
10+ years to get through. It is a complete rewrite of everything with a
number of extremely non-trivial parts. Note also that Unicode is not
even mentioned.

The main failure of the previous PHP6 attempt wasn't actually the choice
of UTF-16 as some people like to claim, it was the fact that too many
things changed all at once. Only a couple of people understood all these
changes and they just didn't have enough time and motivation to carry
these changes through every part of the core and every single extension.
And trying to get help from existing extension maintainers was hard
because the size of the job was daunting. Your list of changes makes
that list seem trivial.

-Rasmus

---

## #72926 — Pierre Joye — 2014-03-05T18:06:43+00:00

URL: https://externals.io/message/72922#72926 · In reply to: #72925

> 
> > […]
>
>  Note also that Unicode is not
> even mentioned.

Unicode has its own page and section, that's why.

> The main failure of the previous PHP6 attempt wasn't actually the choice
> of UTF-16 as some people like to claim,

Right, but the main failure in Unicode support was UTF-16 (to clarify :).

However you are right. I have the feeling that this list is very
optimistic, but a couple of things should be considered (jit f.e. and
APIs cleanup for example).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #72937 — Maxime Veber — 2014-03-05T20:59:30+00:00

URL: https://externals.io/message/72922#72937 · In reply to: #72926

Hello,

I totally love the ideas about BC and cleaning everything. That's what PHP
need and deserve.

Can you be more specific about what you want to change in "Cleanup API and
dead code" part ?

And na na, it's not only for an hypotetic php7 version. We change things or
we do not change !
After all, php move great with minor releases... !

If we want to change, let's to what have to be done *now* !


2014-03-05 19:06 GMT+01:00 Pierre Joye <pierre.php@gmail.com>:

> 
> > […]
>
> Unicode has its own page and section, that's why.
>
> > […]
>
> Right, but the main failure in Unicode support was UTF-16 (to clarify :).
>
> However you are right. I have the feeling that this list is very
> optimistic, but a couple of things should be considered (jit f.e. and
> APIs cleanup for example).
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org

---

## #72957 — johannes@schlueters.de — 2014-03-06T01:05:52+00:00

URL: https://externals.io/message/72922#72957 · In reply to: #72937

> Hello,
> 
> I totally love the ideas about BC and cleaning everything. That's what PHP
> need and deserve.

I assume you are talking about userspae APIs, the often quoted needle vs
haystack etc. If people think this is needed it is trivial to provide
aliases and "fixed" versions for these from an extension (and/or
userspace lib). As nobody has I assume that's more talk than need and
people got accustomed easily.

> Can you be more specific about what you want to change in "Cleanup API and
> dead code" part ?

The mail was about API implementation where there are grown APIs where
parts might not be needed anymore.

> And na na, it's not only for an hypotetic php7 version. We change things or
> we do not change !
> After all, php move great with minor releases... !

There are two requirements

      * people who do
      * thought about backwards compatibility

The first item is hard, the number of people actually doing cleanup
tasks is a small fraction of our relatively small contributor base. So
going by Julien's list, the expected timeframe and the available work
power doing all those things is almost impossible.

Secondly, breaking too much at once is not an option. "Compatibility is
a feature". for one there is lots of legacy code and knowledge, secondly
it tells users that they can invest in PHP and won't get too much update
pain later. See also the "success" of either Python 3 or Perl 6 which
"fixed" too many things giving them low adoption. This by no means we
shouldn't fix and improve things but that's a continuous process. (my
favorite example: register_globals took literally 10 years from us
starting to promote alternatives till we removed the option)


> If we want to change, let's to what have to be done *now* !

We are in constant change. There is barely a language as commonly used
as PHP which changes so rapidly.

johannes

---

## #72973 — Julien Pauli — 2014-03-06T10:53:26+00:00

URL: https://externals.io/message/72922#72973 · In reply to: #72957

On Thu, Mar 6, 2014 at 2:05 AM, Johannes Schlüter
<johannes@schlueters.de> wrote:
> 
> > […]
>
> I assume you are talking about userspae APIs, the often quoted needle vs
> haystack etc. If people think this is needed it is trivial to provide
> aliases and "fixed" versions for these from an extension (and/or
> userspace lib). As nobody has I assume that's more talk than need and
> people got accustomed easily.
>
> > […]
>
> The mail was about API implementation where there are grown APIs where
> parts might not be needed anymore.
>
> > […]
>
> There are two requirements
>
>       * people who do
>       * thought about backwards compatibility
>
> The first item is hard, the number of people actually doing cleanup
> tasks is a small fraction of our relatively small contributor base. So
> going by Julien's list, the expected timeframe and the available work
> power doing all those things is almost impossible.
>
> Secondly, breaking too much at once is not an option. "Compatibility is
> a feature". for one there is lots of legacy code and knowledge, secondly
> it tells users that they can invest in PHP and won't get too much update
> pain later. See also the "success" of either Python 3 or Perl 6 which
> "fixed" too many things giving them low adoption. This by no means we
> shouldn't fix and improve things but that's a continuous process. (my
> favorite example: register_globals took literally 10 years from us
> starting to promote alternatives till we removed the option)
>
>
> > […]
>
> We are in constant change. There is barely a language as commonly used
> as PHP which changes so rapidly.
>
> johannes

Huh, yes, sure, my ideas are a little bit big in dev time, I fully
understand this.

However, they are written now :-)

I fully agree with Johannes and Rasmus by saying that if we break too
many things at the same time, we're never gonna reach our objectives
and this will lead to another failure from us. Unacceptable.
We should take the big cake part by part. Our release process
https://wiki.php.net/rfc/releaseprocess allows us to break BC in ABI
and internal API in minor releases. So we could have a PHP6.0 with
some ideas, 6.1 with another one, 6.2 again, etc... knowing that we
cannot break BC in external API (PHP userland), we then should
concentrate our thoughts on this critical point now.

There is one year gap between every minor, which is just enough (IMO)
to add a new "big" internal feature.
Once more, I'm talking about INTERNAL changes here. We can make those
happen into minors (according to our release process), like we did in
5.4, massively changing the VM compared to 5.3.
PHP6.0 should prepare the code base for future 6.1, 6.2, 6.3 etc...
each one adding another *internal* feature. External API would already
have been prepared/designed in 6.0.

So we have to concentrate on "what features do we want in PHP API
(external one) for the to-be-long 6.X series" right now. Because
after, we won't be able to change the PHP userland API anymore.

I'am also one of the guy thinking that we have to narrow our
timeframes for majors. Majors are about breaking external API, for PHP
users. 10 years is too big, something like 5 years seems more
reasonable.

We also have to master our communication. We all remember PHP4 to PHP5
pain, at this time, but things have changed.
PHP is nowadays much more professionnal, and our distros maintainers
are doing a much better job than 10 or even 5 years ago.

We should not be taken as responsable for the slowness of upgrading
PHP worldwide, but we should always think about easing it.

So to sum things up, I'm not against moving slowly but safely, that's
the way to move.
We have a clear view of our release process, one minor per year where
we are allowed to break internals and refactor internals and add new
internals stuff, one rev per month for bug fixes, and one major every
{{- we don't know but 5 years seems like right, why not vote this part
all together? -}}


Julien.Pauli

---

## #72984 — Stas Malyshev — 2014-03-06T20:59:49+00:00

URL: https://externals.io/message/72922#72984 · In reply to: #72926

Hi!

> However you are right. I have the feeling that this list is very 
> optimistic, but a couple of things should be considered (jit f.e.
> and APIs cleanup for example).

I think if we want the next major happen on reasonable timeframe, we
should be extremely wary of "rewrite everything" wishlist items,
especially ones without somebody making very strong commitment at
actually seeing them through (and note that rewriting API means that
code depending on the API should be redone too). Whatever is one's
estimate of how much work would such thing require, it's usually order
of magnitude or more off, and not to the good side, when you're touching
deep infrastructure things. So I think we need to separate "pie in the
sky" items from items that we have an idea where to go with them and
items that would produce real improvement visible for users. As an
example, most users wouldn't care much about hooks in the optimizer or
how exactly source code is parsed, but would care a lot if we got named
params support or Unicode support. I'm not saying we shouldn't do the
former, just to separate lists into user and non-user part and be
realistic about how hard some of these are, and prioritize the user part.

I think if we try to bite off too much we've end up where Unicode effort
ended - a lot of work ending up in achieving nothing. I think we need to
have a plan of something that can realistically be done in, say, a year
or two, and that makes common users (ones that don't care how exactly
our parsing library is called but have thousands upon thousands of lines
of code to upgrade and thousands of developers to adopt it) be eager to
buy into it, something that makes their lives immediately better and
worth the pain of the upgrade.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #72987 — Pierre Joye — 2014-03-07T06:26:27+00:00

URL: https://externals.io/message/72922#72987 · In reply to: #72984

hi Stas,


> Hi!
>
> > […]
>
> I think if we want the next major happen on reasonable timeframe, we
> should be extremely wary of "rewrite everything" wishlist items,
> especially ones without somebody making very strong commitment at
> actually seeing them through (and note that rewriting API means that
> code depending on the API should be redone too). Whatever is one's
> estimate of how much work would such thing require, it's usually order
> of magnitude or more off, and not to the good side, when you're touching
> deep infrastructure things. So I think we need to separate "pie in the
> sky" items from items that we have an idea where to go with them and
> items that would produce real improvement visible for users. As an
> example, most users wouldn't care much about hooks in the optimizer or
> how exactly source code is parsed, but would care a lot if we got named
> params support or Unicode support. I'm not saying we shouldn't do the
> former, just to separate lists into user and non-user part and be
> realistic about how hard some of these are, and prioritize the user part.
>
> I think if we try to bite off too much we've end up where Unicode effort
> ended - a lot of work ending up in achieving nothing. I think we need to
> have a plan of something that can realistically be done in, say, a year
> or two, and that makes common users (ones that don't care how exactly
> our parsing library is called but have thousands upon thousands of lines
> of code to upgrade and thousands of developers to adopt it) be eager to
> buy into it, something that makes their lives immediately better and
> worth the pain of the upgrade.

Amen :)

-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #72988 — Lester Caine — 2014-03-07T08:52:20+00:00

URL: https://externals.io/message/72922#72988 · In reply to: #72984

Stas Malyshev wrote:
> I think if we try to bite off too much we've end up where Unicode effort
> ended - a lot of work ending up in achieving nothing. I think we need to
> have a plan of something that can realistically be done in, say, a year
> or two, and that makes common users (ones that don't care how exactly
> our parsing library is called but have thousands upon thousands of lines
> of code to upgrade and thousands of developers to adopt it) be eager to
> buy into it, something that makes their lives immediately better and
> worth the pain of the upgrade.

And there are good examples outside PHP that prove the point :)
Just been playing with another 'python' powered package that is still P2 because 
the developer does not have time to do all the work involved to move to P3. Just 
how many important PHP applications are still stuck pre PHP5.4 and need some TLC 
to bring them forward ...
It is irritating that we have to work with quite so many different languages. It 
would be nice if PHP was tidy enough to be the single base for web based services!

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk