Re: PHP6 thoughts about Engine changes

On Thu, Mar 6, 2014 at 2:05 AM, Johannes Schlüter <johannes@schlueters.de> wrote: > On Wed, 2014-03-05 at 21:59 +0100, Maxime Veber 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 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 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