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
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.
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
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.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
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:
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.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
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
On Thu, Mar 6, 2014 at 2:05 AM, Johannes Schlüter
johannes@schlueters.de wrote:
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 compatibilityThe 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
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
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
hi Stas,
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.
Amen :)
--
Pierre
@pierrejoye | http://www.libgd.org
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