Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Remove PHP 4 Constructors »

[RFC] Remove PHP 4 Constructors

php.internals

Levi Morrison

11 years ago
Dear Internals, I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If accepted, methods with the same name as their defining class will no longer be recognized as constructors. As noted in the RFC, there are already many situations where we do not recognize these methods as constructors, such as in namespaces and traits and when `function __construct` is also present. Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. Cheers, Levi Morrison [1]: https://wiki.php.net/rfc/remove_php4_constructors [2]: https://github.com/TazeTSchnitzel/PHP4_Constructor_Finder [3]: http://phpmd.org/rules/naming.html#constructorwithnameasenclosingclass

Julien Breux

11 years ago
I think that it is great time to end to PHP 4 constructors system for PHP 7. IMO, It's a good RFC. On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison <levim@php.net> wrote:

Kris Craig

11 years ago
On Tue, Nov 18, 2014 at 3:26 PM, Julien Breux <julien.breux@gmail.com> wrote:
> I think that it is great time to end to PHP 4 constructors system for PHP > 7. > > IMO, It's a good RFC. >
Agreed. I was going to suggest we throw E_DEPRECATED for 5.x, but you already have that covered in the RFC. I don't see anything wrong with this proposal, in fact. In hindsight, it probably would've been better if we had started raising E_DEPRECATED for it back in 5.0, but better now than never. We certainly have no obligation to support BC on features that became obsolete with PHP 4. +1 on this. --Kris

Yasuo Ohgaki

11 years ago
Hi all, On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison <levim@php.net> wrote:
> I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If > accepted, methods with the same name as their defining class will no > longer be recognized as constructors. As noted in the RFC, there are > already many situations where we do not recognize these methods as > constructors, such as in namespaces and traits and when `function > __construct` is also present. > > Andrea Faulds has kindly written a utility that identifies when a PHP > 4 constructor is defined[2]. It does not automatically change the code > for liability reasons. The utility PHPMD[3] can also detect this but > has a false positive when `__construct` is also defined. >
No reason to keep old constructor for PHP7. IMHO. +1 for removing it PHP7, announce depreciation now. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Julien Pauli

11 years ago
On Wed, Nov 19, 2014 at 5:15 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi all, > > On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison <levim@php.net> wrote: > >> I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If >> accepted, methods with the same name as their defining class will no >> longer be recognized as constructors. As noted in the RFC, there are >> already many situations where we do not recognize these methods as >> constructors, such as in namespaces and traits and when `function >> __construct` is also present. >> >> Andrea Faulds has kindly written a utility that identifies when a PHP >> 4 constructor is defined[2]. It does not automatically change the code >> for liability reasons. The utility PHPMD[3] can also detect this but >> has a false positive when `__construct` is also defined. >> > > No reason to keep old constructor for PHP7. IMHO. > +1 for removing it PHP7, announce depreciation now.
This is obviously a +1. Julien.Pauli

Patrick ALLAERT

11 years ago
Le Wed Nov 19 2014 at 9:31:50 AM, Julien Pauli <jpauli@php.net> a écrit :
> On Wed, Nov 19, 2014 at 5:15 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > > Hi all, > > > > On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison <levim@php.net> wrote: > > > >> I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If > >> accepted, methods with the same name as their defining class will no > >> longer be recognized as constructors. As noted in the RFC, there are > >> already many situations where we do not recognize these methods as > >> constructors, such as in namespaces and traits and when `function > >> __construct` is also present. > >> > >> Andrea Faulds has kindly written a utility that identifies when a PHP > >> 4 constructor is defined[2]. It does not automatically change the code > >> for liability reasons. The utility PHPMD[3] can also detect this but > >> has a false positive when `__construct` is also defined. > >> > > > > No reason to keep old constructor for PHP7. IMHO. > > +1 for removing it PHP7, announce depreciation now. > > This is obviously a +1. > > Julien.Pauli >
+1

Ferenc Kovacs

11 years ago
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison <levim@php.net> wrote:
> Dear Internals, > > I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If > accepted, methods with the same name as their defining class will no > longer be recognized as constructors. As noted in the RFC, there are > already many situations where we do not recognize these methods as > constructors, such as in namespaces and traits and when `function > __construct` is also present. > > Andrea Faulds has kindly written a utility that identifies when a PHP > 4 constructor is defined[2]. It does not automatically change the code > for liability reasons. The utility PHPMD[3] can also detect this but > has a false positive when `__construct` is also defined. > > Cheers, > Levi Morrison > > > [1]: https://wiki.php.net/rfc/remove_php4_constructors > [2]: https://github.com/TazeTSchnitzel/PHP4_Constructor_Finder > [3]: > http://phpmd.org/rules/naming.html#constructorwithnameasenclosingclass > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
+1 from me.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Remi Collet

11 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 19/11/2014 00:11, Levi Morrison a écrit :
> [1]: https://wiki.php.net/rfc/remove_php4_constructors
This will just kill PEAR and most of available libraries on PEAR forge. Yes they are still some use of them Yes keeping PHP 4 for PEAR is a bad idea Remi. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlRsniIACgkQYUppBSnxahilDwCgtcsNH9UtJFtkVkY0KwqxRiZn oZgAoLzKJ4zbO6mBerkivLziwFahOAF/ =pQ60 -----END PGP SIGNATURE-----

Alain Williams

11 years ago
On Wed, Nov 19, 2014 at 02:41:54PM +0100, Remi Collet wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 19/11/2014 00:11, Levi Morrison a écrit : > > [1]: https://wiki.php.net/rfc/remove_php4_constructors > > This will just kill PEAR and most of available libraries on PEAR forge. > > Yes they are still some use of them > Yes keeping PHP 4 for PEAR is a bad idea
Maybe this would spur PEAR to moving to a modern PHP, they could always maintain a separate PEAR legacy. PHP 4 support ended some 6 years ago.
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>

Maxime Veber

11 years ago
Outch, I didn't know that this use case was still valid. Yes, ofc, +1. 2014-11-19 14:46 GMT+01:00 Alain Williams <addw@phcomp.co.uk>:

Rowan Collins

11 years ago
Alain Williams wrote on 19/11/2014 13:46:
> On Wed, Nov 19, 2014 at 02:41:54PM +0100, Remi Collet wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Le 19/11/2014 00:11, Levi Morrison a écrit : >>> [1]: https://wiki.php.net/rfc/remove_php4_constructors >> This will just kill PEAR and most of available libraries on PEAR forge. >> >> Yes they are still some use of them >> Yes keeping PHP 4 for PEAR is a bad idea > Maybe this would spur PEAR to moving to a modern PHP, they could always maintain > a separate PEAR legacy. PHP 4 support ended some 6 years ago. >
PEAR is not a single organisation who can mass update all the modules; the guidelines could be updated, if they haven't been already, but there would still be a whole repository full of libraries which used this. Now, whether that's acceptable or not, I don't know, but it does highlight the size of the compatibility break. Regards,
-- Rowan Collins [IMSoP]

Alain Williams

11 years ago
On Wed, Nov 19, 2014 at 02:27:12PM +0000, Rowan Collins wrote:
> PEAR is not a single organisation who can mass update all the > modules; the guidelines could be updated, if they haven't been > already, but there would still be a whole repository full of > libraries which used this. > > Now, whether that's acceptable or not, I don't know, but it does > highlight the size of the compatibility break.
How many servers are stuck on PHP 4 ? Of those 'stuck' servers, how many have applications still under active development ? The point is: how many people would get annoyed if PEAR stopped supporting PHP 4 ? IMHO: making PHP 5.3+ the PEAR baseline would not seem unreasonable.
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>

Andrey Andreev

11 years ago
Hi, On Wed, Nov 19, 2014 at 4:33 PM, Alain Williams <addw@phcomp.co.uk> wrote:
> On Wed, Nov 19, 2014 at 02:27:12PM +0000, Rowan Collins wrote: > >> PEAR is not a single organisation who can mass update all the >> modules; the guidelines could be updated, if they haven't been >> already, but there would still be a whole repository full of >> libraries which used this. >> >> Now, whether that's acceptable or not, I don't know, but it does >> highlight the size of the compatibility break. > > How many servers are stuck on PHP 4 ? > > Of those 'stuck' servers, how many have applications still under active > development ? > > The point is: how many people would get annoyed if PEAR stopped supporting PHP 4 ? > > IMHO: making PHP 5.3+ the PEAR baseline would not seem unreasonable.
Nope. The point is, how much of that code *depends on PHP4-style constructors*, which work perfectly fine in PHP 5.x. Regardless, it's time to put it in the past, so a +1 from me for this RFC. Cheers, Andrey.

Ferenc Kovacs

11 years ago
On Wed, Nov 19, 2014 at 3:33 PM, Alain Williams <addw@phcomp.co.uk> wrote:
> On Wed, Nov 19, 2014 at 02:27:12PM +0000, Rowan Collins wrote: > > > PEAR is not a single organisation who can mass update all the > > modules; the guidelines could be updated, if they haven't been > > already, but there would still be a whole repository full of > > libraries which used this. > > > > Now, whether that's acceptable or not, I don't know, but it does > > highlight the size of the compatibility break. > > How many servers are stuck on PHP 4 ? > > Of those 'stuck' servers, how many have applications still under active > development ? > > The point is: how many people would get annoyed if PEAR stopped supporting > PHP 4 ? > > IMHO: making PHP 5.3+ the PEAR baseline would not seem unreasonable. > >
There were already discussion about bumping the php requirements for the next PEAR package: http://comments.gmane.org/gmane.comp.php.pear.devel/50823 But what it is more important is that even if some PEAR packages will be getting new releases with modern/refactored APIs with bumped major versions, that will still not break the already existing installation, and people will still be able to install the latest package version which supports their php version (and it would be still possible to continue releasing patch versions for security updates for the php4 compatible versions). So while I agree that PEAR in it's current form will be the biggest public repository with code affected by this change, it isn't like they can't move forward or that users using PEAR for their projects will be left without an upgrade path and plenty of time to execute it.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Johannes Schlueter

11 years ago
On Wed, 2014-11-19 at 14:33 +0000, Alain Williams wrote:
> How many servers are stuck on PHP 4 ? > > Of those 'stuck' servers, how many have applications still under active > development ? > > The point is: how many people would get annoyed if PEAR stopped supporting PHP 4 ?
The point about breaking this is *not* PHP 4 compatibility but compatibility between PECL packages. The name of the constructor method is part of the API. Think about code like this in module A: class A_class { function A_class() { } } and then module B extending this: class B_class extends A_class { function B_class() { A_class(); } } I also wonder how Andrea's tool handles more indirect cases (C_class extends B_class, while B_class has no ctor so C_class calls directly A_class's ctor) So I'm -1 on this. johannes

Laruence

11 years ago
On Thu, Nov 20, 2014 at 5:43 PM, Johannes Schlüter <johannes@schlueters.de> wrote:
> On Wed, 2014-11-19 at 14:33 +0000, Alain Williams wrote: >> How many servers are stuck on PHP 4 ? >> >> Of those 'stuck' servers, how many have applications still under active >> development ? >> >> The point is: how many people would get annoyed if PEAR stopped supporting PHP 4 ? > > The point about breaking this is *not* PHP 4 compatibility but > compatibility between PECL packages. The name of the constructor method > is part of the API. > > Think about code like this in module A: > > class A_class { > function A_class() { } > } > > and then module B extending this: > > class B_class extends A_class { > function B_class() { > A_class(); > } > } > > I also wonder how Andrea's tool handles more indirect cases (C_class > extends B_class, while B_class has no ctor so C_class calls directly > A_class's ctor) > > So I'm -1 on this.
I am with you here. leave it there doesn't hurt anybody. but remove it will. why we need to ? thanks
> > johannes > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- Xinchen Hui @Laruence http://www.laruence.com/

Andrey Andreev

11 years ago
Hi, On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui <laruence@php.net> wrote:
> > leave it there doesn't hurt anybody. but remove it will. why we need to ? >
Leaving it does hurt. Most developers with no PHP4 experience don't know that such a feature exists and spend hours trying to figure out why a parent class' constructor isn't getting called when it's not overriden by self::__construct(). PHP can't support everything forever, old and nowadays rarely used syntax like this one must go away. Cheers, Andrey.

Laruence

11 years ago
On Thu, Nov 20, 2014 at 10:32 PM, Andrey Andreev <narf@devilix.net> wrote:
> Hi, > > On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui <laruence@php.net> wrote: >> >> leave it there doesn't hurt anybody. but remove it will. why we need to ? >> > > Leaving it does hurt. Most developers with no PHP4 experience don't > know that such a feature exists and spend hours trying to figure out > why a parent class' constructor isn't getting called when it's not > overriden by self::__construct().
I really doubt "most" here. developers with c++ experience must feel it's very friendly. thanks
> > PHP can't support everything forever, old and nowadays rarely used > syntax like this one must go away. > > Cheers, > Andrey.
-- Xinchen Hui @Laruence http://www.laruence.com/

Levi Morrison

11 years ago
On Thu, Nov 20, 2014 at 2:43 AM, Johannes Schlüter <johannes@schlueters.de> wrote:
> On Wed, 2014-11-19 at 14:33 +0000, Alain Williams wrote: >> How many servers are stuck on PHP 4 ? >> >> Of those 'stuck' servers, how many have applications still under active >> development ? >> >> The point is: how many people would get annoyed if PEAR stopped supporting PHP 4 ? > > The point about breaking this is *not* PHP 4 compatibility but > compatibility between PECL packages. The name of the constructor method > is part of the API. > > Think about code like this in module A: > > class A_class { > function A_class() { } > } > > and then module B extending this: > > class B_class extends A_class { > function B_class() { > A_class(); > } > } > > I also wonder how Andrea's tool handles more indirect cases (C_class > extends B_class, while B_class has no ctor so C_class calls directly > A_class's ctor) > > So I'm -1 on this.
I just want to make sure I understand you correctly: you are saying you are voting no on this RFC because a tool, which is not part of this RFC but we kindly provide, doesn't detect when a certain thing is called?

Johannes Schlueter

11 years ago
On Thu, 2014-11-20 at 09:11 -0700, Levi Morrison wrote:
> > So I'm -1 on this. > > I just want to make sure I understand you correctly: you are saying > you are voting no on this RFC because a tool, which is not part of > this RFC but we kindly provide, doesn't detect when a certain thing is > called?
It is a non-trivial change. Fixing this is not always as some people might suggest. If we like it or not there is tons of code out there depending on this feature. Breaking code, which worked for 15 years, where we even distribute such code in our main distribution (pear.phar is full of it) is not an option. And it is not only PHP - just looked at wordpress and there are quite a few classes in there where PHP 4 style ctors are used.and which aren't marked final/public and as such are part of the API, meaning that WP modules might depend on that. Consequence there is that once the feature is removed WP users need a new major WP version and new versions of modules before they can upgrade. This will lead to very slow adoption of a new PHP version. We can deprecate it in 7 (and fix code in our distribution) and then take a next step in a later version, though. This gives folks like WP time to update their codebase and be ready when our larer version comes out. johannes

Rowan Collins

11 years ago
Johannes Schlüter wrote on 20/11/2014 17:00:
> We can deprecate it in 7 (and fix code in our distribution) and then > take a next step in a later version, though. This gives folks like WP > time to update their codebase and be ready when our larer version comes > out.
+1 for officially deprecating this for a while before removing; currently, there's not even an E_STRICT when defining or using old-style constructors. The manual isn't particular clear either:
> For backwards compatibility, if PHP 5 cannot find a __construct()
<http://php.net/manual/en/language.oop5.decon.php#object.construct> function for a given class, and the class did not inherit one from a parent class, it will search for the old-style constructor function, by the name of the class. I notice the RFC does propose deprecation, but in 5.7; that's predicated on a 5.7 being released, which I know some people are not in favour of. Has there been a formal vote on whether 5.7 should exist as a lightweight "last 5.x" shortly before 7.x? Even with that, there is the question of whether 5.7 would give users long enough to make sure everything was compatible with this change. Regards,
-- Rowan Collins [IMSoP]

Levi Morrison

11 years ago
>> I just want to make sure I understand you correctly: you are saying >> you are voting no on this RFC because a tool, which is not part of >> this RFC but we kindly provide, doesn't detect when a certain thing is >> called? > > It is a non-trivial change. Fixing this is not always as some people > might suggest.
1) Identify PHP 4 constructors using one of several tools (including upgrading to PHP 5.7 and getting E_DEPRECATEDs). 2) Use one of the several tools that support method rename refactoring (Netbeans, PhpStorm, and others) to rename the methods to __construct. You could probably automate it with a very high degree of success; I just don't want to automatically change code for liability reasons. I think you are exaggerating the required work given the tools we have at our disposal… …but that's okay. You can think and vote however you chose.
> We can deprecate it in 7 (and fix code in our distribution) and then > take a next step in a later version, though.
I am proposing E_DEPRECATED in PHP 5.7, just as the RFC for using multiple default statements in switches (which was accepted, by the way). Updating to PHP 5.7 first gives you more time to prepare for this and other BC breaks for PHP 7. There are already a few, and I suspect we'll have a few more before it's shipped.

Rowan Collins

11 years ago
On 20 November 2014 20:54:00 GMT, Levi Morrison <levim@php.net> wrote:
>>> I just want to make sure I understand you correctly: you are saying >>> you are voting no on this RFC because a tool, which is not part of >>> this RFC but we kindly provide, doesn't detect when a certain thing >is >>> called? >> >> It is a non-trivial change. Fixing this is not always as some people >> might suggest. > >1) Identify PHP 4 constructors using one of several tools (including >upgrading to PHP 5.7 and getting E_DEPRECATEDs). >2) Use one of the several tools that support method rename refactoring >(Netbeans, PhpStorm, and others) to rename the methods to __construct. > >You could probably automate it with a very high degree of success; I >just don't want to automatically change code for liability reasons. I >think you are exaggerating the required work given the tools we have >at our disposal…
The problem is that the constructor is part of the public API (for inheritance purposes) so the required refactoring is not necessarily isolated to one project, or even doable by one developer. The maintainer of the library must first release a version with the new constructors in place, and the consumer of the library must then audit their code for anything relying on the old constructor. Supporting various combinations of PHP 5/7, old/new lib, and old/new consumer code is then messy at best. I agree that it's perfectly doable, but it's not as easy to migrate as, say, a syntax change.

Johannes Schlueter

11 years ago
On Thu, 2014-11-20 at 13:54 -0700, Levi Morrison wrote:
> > It is a non-trivial change. Fixing this is not always as some people > > might suggest. > > 1) Identify PHP 4 constructors using one of several tools (including > upgrading to PHP 5.7 and getting E_DEPRECATEDs). > 2) Use one of the several tools that support method rename refactoring > (Netbeans, PhpStorm, and others) to rename the methods to __construct. > > You could probably automate it with a very high degree of success; I > just don't want to automatically change code for liability reasons. I > think you are exaggerating the required work given the tools we have > at our disposal…
No you can't. (ok *you* can but not 90% of our users, those depend on external libraries/tools and those can't simply change their API without hurting their adoption rate, which in turn hurts our adoption rate)
> I am proposing E_DEPRECATED in PHP 5.7, just as the RFC for using > multiple default statements in switches (which was accepted, by the > way). > > Updating to PHP 5.7 first gives you more time to prepare for this and > other BC breaks for PHP 7. There are already a few, and I suspect > we'll have a few more before it's shipped.
Yay! Instead of helping users to keep up to date and respecting their needs we give them reasons to stay on old versions for making things "cleaner". How wonderful. All things said for this thread. johannes

Chris Wright

11 years ago
On 19 November 2014 14:27, Rowan Collins <rowan.collins@gmail.com> wrote:
> Alain Williams wrote on 19/11/2014 13:46: > >> On Wed, Nov 19, 2014 at 02:41:54PM +0100, Remi Collet wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Le 19/11/2014 00:11, Levi Morrison a écrit : >>> >>>> [1]: https://wiki.php.net/rfc/remove_php4_constructors >>>> >>> This will just kill PEAR and most of available libraries on PEAR forge. >>> >>> Yes they are still some use of them >>> Yes keeping PHP 4 for PEAR is a bad idea >>> >> Maybe this would spur PEAR to moving to a modern PHP, they could always >> maintain >> a separate PEAR legacy. PHP 4 support ended some 6 years ago. >> >> > PEAR is not a single organisation who can mass update all the modules; the > guidelines could be updated, if they haven't been already, but there would > still be a whole repository full of libraries which used this. > > Now, whether that's acceptable or not, I don't know, but it does highlight > the size of the compatibility break. >
It would be quite easy to write a tool to detect classes that use the old style, and even automatically fix them in most cases. As BC breaks go, this is about as minimal as it gets for package maintainers. Note that, for users who are insane enough to expect to maintain PHP4-7 support in a single codebase, it's also easily possible to work with both styles even after this change is introduced: class Foo { function Foo() { // invoked as the ctor in PHP4 $this->__construct(); } function __construct() { // invoked as the ctor in PHP5/7 } }

Alain Williams

11 years ago
On Wed, Nov 19, 2014 at 02:41:09PM +0000, Chris Wright wrote:
> Note that, for users who are insane enough to expect to maintain PHP4-7 > support in a single codebase, it's also easily possible to work with both > styles even after this change is introduced: > ...
It is a problem trying to maintain code for different versions of PHP, especially where there are syntax differences. It would be really nice to have some sort of conditional compilation as in C. Eg: It would be nice to be able to do something like: try { .... # if PHP_VERSION_ID > 50500 } catch(PDOException $e) { .... } finally { ... tidy up } # else } catch(PDOException $e) { ... tidy up not quite where I want it .... } # endif OK: '#' might not be a good character since it is start of comment, but that is the idea.
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>

Andrew Faulds

11 years ago
> On 19 Nov 2014, at 15:07, Alain Williams <addw@phcomp.co.uk> wrote: > > It is a problem trying to maintain code for different versions of PHP, > especially where there are syntax differences. It would be really nice to have > some sort of conditional compilation as in C. Eg: > > It would be nice to be able to do something like: > > try { > .... > > # if PHP_VERSION_ID > 50500 > } catch(PDOException $e) { > .... > } finally { > ... tidy up > } > # else > } catch(PDOException $e) { > ... tidy up not quite where I want it > .... > } > # endif > > OK: '#' might not be a good character since it is start of comment, but that is > the idea.
You could actually run the C preprocessor on your PHP codebase if you wanted! But yes, I can see there might be a need for conditional compilation. To a certain extent we already have this, in that you can conditionally define functions and classes. Perhaps this could be extended? Conditionally defining methods? class FooBar { if (PHP_VERSION_ID < 50000) { public function FooBar() { $this->__construct(); } } public function __foobar() { } }
-- Andrea Faulds http://ajf.me/

Julien Pauli

11 years ago
On Wed, Nov 19, 2014 at 4:10 PM, Andrea Faulds <ajf@ajf.me> wrote:
> >> On 19 Nov 2014, at 15:07, Alain Williams <addw@phcomp.co.uk> wrote: >> >> It is a problem trying to maintain code for different versions of PHP, >> especially where there are syntax differences. It would be really nice to have >> some sort of conditional compilation as in C. Eg: >> >> It would be nice to be able to do something like: >> >> try { >> .... >> >> # if PHP_VERSION_ID > 50500 >> } catch(PDOException $e) { >> .... >> } finally { >> ... tidy up >> } >> # else >> } catch(PDOException $e) { >> ... tidy up not quite where I want it >> .... >> } >> # endif >> >> OK: '#' might not be a good character since it is start of comment, but that is >> the idea. > > You could actually run the C preprocessor on your PHP codebase if you wanted! > > But yes, I can see there might be a need for conditional compilation. To a certain extent we already have this, in that you can conditionally define functions and classes. Perhaps this could be extended? Conditionally defining methods? > > class FooBar { > if (PHP_VERSION_ID < 50000) { > public function FooBar() { > $this->__construct(); > } > } > > public function __foobar() { > > } > } > --
[Off Topic] It's been a long time I've been thinking about having a compile-time preprocessor integrated into our parser/compiler stack. I would design it just to support #migration tokens, and nothing more. This would really ease migrations, with no runtime impact at all, and the possibility to use any syntax, knowing it will get compiled, which is not possible nowadays. Like the C preprocessor. And it wouldn't be that hard to add to our codebase, as there should not be any runtime impact, just a two-pass parser Anyone interested can contact me :-) [/Off Topic] Julien.P

Alain Williams

11 years ago
On Wed, Nov 19, 2014 at 07:17:48PM +0100, Julien Pauli wrote:
> [Off Topic] > > It's been a long time I've been thinking about having a compile-time > preprocessor integrated into our parser/compiler stack. > I would design it just to support #migration tokens, and nothing more. > This would really ease migrations, with no runtime impact at all, and > the possibility to use any syntax, knowing it will get compiled, which > is not possible nowadays. > Like the C preprocessor. And it wouldn't be that hard to add to our > codebase, as there should not be any runtime impact, just a two-pass > parser > > Anyone interested can contact me :-) > > [/Off Topic]
If you do, then please back port it to at least PHP 5.3 If you did then we would be able to write code with new syntaxes (that won't compile under 5.3/whatever) and automatically use them when the code is run under whatever version supports the syntax. Going back to the example that I gave & thinking a bit, a '$#' at the start of line (not recognised anywhere else) would work. It is an error under different circumstances and is sufficiently reminicent of C to be helpful of those of us with that background. $# if PHP_VERSION_ID > 50500 $# else $# endif Without wanting to make it too complicated, it might be nice to allow a 'set' (or 'define'), this would allow setting of flags, eg: $# if PHP_VERSION_ID > 50500 $# set FINALLY 1 $# endif $# if FINALLY ... $#endif
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>

Julien Pauli

11 years ago
On Fri, Nov 21, 2014 at 5:55 PM, Alain Williams <addw@phcomp.co.uk> wrote:
> On Wed, Nov 19, 2014 at 07:17:48PM +0100, Julien Pauli wrote: > >> [Off Topic] >> >> It's been a long time I've been thinking about having a compile-time >> preprocessor integrated into our parser/compiler stack. >> I would design it just to support #migration tokens, and nothing more. >> This would really ease migrations, with no runtime impact at all, and >> the possibility to use any syntax, knowing it will get compiled, which >> is not possible nowadays. >> Like the C preprocessor. And it wouldn't be that hard to add to our >> codebase, as there should not be any runtime impact, just a two-pass >> parser >> >> Anyone interested can contact me :-) >> >> [/Off Topic] > > If you do, then please back port it to at least PHP 5.3 If you did then we would > be able to write code with new syntaxes (that won't compile under 5.3/whatever) > and automatically use them when the code is run under whatever version supports > the syntax. > > Going back to the example that I gave & thinking a bit, a '$#' at the start of > line (not recognised anywhere else) would work. It is an error under different > circumstances and is sufficiently reminicent of C to be helpful of those of us > with that background. > > $# if PHP_VERSION_ID > 50500 > $# else > $# endif > > Without wanting to make it too complicated, it might be nice to allow a 'set' > (or 'define'), this would allow setting of flags, eg: > > $# if PHP_VERSION_ID > 50500 > $# set FINALLY 1 > $# endif > > $# if FINALLY > ... > $#endif > > --
Hello, We are (because I'm not alone anymore having this idea and already got private feedback) working on something much more simple, based on the declare() structure. The idea is to have something that could make PHP compile only syntax it knows, and not older syntax (prevent parse errors or use a better implementation). Obviously, this will not be pushed to stable branches, and could target PHP7 if we decide to push it to an RFC. declare(php_version >= 5.6) { function foo($a, ...$b) { } } Very first ideas, need more reflection, then an RFC draft Julien.P

Ralf Lang

11 years ago
On 19.11.2014 16:07, Alain Williams wrote:
> On Wed, Nov 19, 2014 at 02:41:09PM +0000, Chris Wright wrote: > > >> Note that, for users who are insane enough to expect to maintain PHP4-7 >> support in a single codebase, it's also easily possible to work with both >> styles even after this change is introduced: >> ... > > It is a problem trying to maintain code for different versions of PHP, > especially where there are syntax differences.
Not in this case. Old PHP 4 code (regarding constructors) works through all PHP 5.x - New PHP 5 code has been working for the last 6 or 7 years worth of PHP releases and will continue to work. Code which has duplicate constructors (or one calling the other) will work on both platforms (only regarding constructors). +1 for the change even though or because it will separate some of the PEAR heritage from modern platforms if unchanged/unmaintained.
-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Nikita Popov

11 years ago
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison <levim@php.net> wrote:
> Dear Internals, > > I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If > accepted, methods with the same name as their defining class will no > longer be recognized as constructors. As noted in the RFC, there are > already many situations where we do not recognize these methods as > constructors, such as in namespaces and traits and when `function > __construct` is also present. > > Andrea Faulds has kindly written a utility that identifies when a PHP > 4 constructor is defined[2]. It does not automatically change the code > for liability reasons. The utility PHPMD[3] can also detect this but > has a false positive when `__construct` is also defined. > > Cheers, > Levi Morrison >
I'm +1 on this RFC. I've lost count of the number of times I had to debug some "completely impossible" behavior I got while writing quick testing code (which is obviously not namespaced), because I accidentally created a class "Test" with a method "test" or similar. I'm also pretty confident that we can provide robust tooling for automatically porting code to new constructors - including updating parent:: call references if need be. Don't see how that would be a particular issue here. Nikita

Rowan Collins

11 years ago
Nikita Popov wrote on 21/11/2014 16:22:
> I'm also pretty confident that we can provide robust tooling for > automatically porting code to new constructors - including updating > parent:: call references if need be. Don't see how that would be a > particular issue here.
Given the contents of your github repo, I'm inclined to take your word for it on that! :)

Sara Golemon

11 years ago
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison <levim@php.net> wrote:
> https://wiki.php.net/rfc/remove_php4_constructors >
Entirely +1 on removing them in PHP7. Did we decide on having a 5.7 release? (I was on vacation and may have missed this) If so, then the timeline is perfect, one full release to deprecate, and a major-version bump to remove on. Two thumbs up, would upvote again. -Sara

Adam Harvey

11 years ago
On 25 November 2014 at 10:36, Sara Golemon <pollita@php.net> wrote:
> On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison <levim@php.net> wrote: >> https://wiki.php.net/rfc/remove_php4_constructors >> > Entirely +1 on removing them in PHP7. > > Did we decide on having a 5.7 release? (I was on vacation and may have > missed this) If so, then the timeline is perfect, one full release to > deprecate, and a major-version bump to remove on.
Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC pases, I was going to write up the "let's do a 5.7" RFC if nobody else did. Adam

Pierre Joye

11 years ago
On Nov 26, 2014 1:39 AM, "Adam Harvey" <aharvey@php.net> wrote:
> > On 25 November 2014 at 10:36, Sara Golemon <pollita@php.net> wrote: > > On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison <levim@php.net> wrote: > >> https://wiki.php.net/rfc/remove_php4_constructors > >> > > Entirely +1 on removing them in PHP7. > > > > Did we decide on having a 5.7 release? (I was on vacation and may have > > missed this) If so, then the timeline is perfect, one full release to > > deprecate, and a major-version bump to remove on. > > Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC > pases, I was going to write up the "let's do a 5.7" RFC if nobody else > did.
Yes, we did. And we decided not to have it because it will impact php7 timeline.

Adam Harvey

11 years ago
On 15 January 2015 at 17:35, Pierre Joye <pierre.php@gmail.com> wrote:
> > On Nov 26, 2014 1:39 AM, "Adam Harvey" <aharvey@php.net> wrote: >> >> On 25 November 2014 at 10:36, Sara Golemon <pollita@php.net> wrote: >> > On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison <levim@php.net> wrote: >> >> https://wiki.php.net/rfc/remove_php4_constructors >> >> >> > Entirely +1 on removing them in PHP7. >> > >> > Did we decide on having a 5.7 release? (I was on vacation and may have >> > missed this) If so, then the timeline is perfect, one full release to >> > deprecate, and a major-version bump to remove on. >> >> Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC >> pases, I was going to write up the "let's do a 5.7" RFC if nobody else >> did. > > Yes, we did. And we decided not to have it because it will impact php7 > timeline.
That e-mail was almost two months ago. :) Adam

Pierre Joye

11 years ago
On Fri, Jan 16, 2015 at 8:14 AM, Adam Harvey <aharvey@php.net> wrote:
> On 15 January 2015 at 17:35, Pierre Joye <pierre.php@gmail.com> wrote: >> >> On Nov 26, 2014 1:39 AM, "Adam Harvey" <aharvey@php.net> wrote: >>> >>> On 25 November 2014 at 10:36, Sara Golemon <pollita@php.net> wrote: >>> > On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison <levim@php.net> wrote: >>> >> https://wiki.php.net/rfc/remove_php4_constructors >>> >> >>> > Entirely +1 on removing them in PHP7. >>> > >>> > Did we decide on having a 5.7 release? (I was on vacation and may have >>> > missed this) If so, then the timeline is perfect, one full release to >>> > deprecate, and a major-version bump to remove on. >>> >>> Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC >>> pases, I was going to write up the "let's do a 5.7" RFC if nobody else >>> did. >> >> Yes, we did. And we decided not to have it because it will impact php7 >> timeline. > > That e-mail was almost two months ago. :)
lol he just showed up on top today, ah joy :)
-- Pierre @pierrejoye | http://www.libgd.org

Matteo Beccati

11 years ago
Hi everyone,
> I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If > accepted, methods with the same name as their defining class will no > longer be recognized as constructors. As noted in the RFC, there are > already many situations where we do not recognize these methods as > constructors, such as in namespaces and traits and when `function > __construct` is also present. > > Andrea Faulds has kindly written a utility that identifies when a PHP > 4 constructor is defined[2]. It does not automatically change the code > for liability reasons. The utility PHPMD[3] can also detect this but > has a false positive when `__construct` is also defined.
I still think this (and other) BC breaks should be avoided if we want to maximize PHP7 adoption, but I've started working on this: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/970 which is a patch to php-cs-fixer that would be helpful to ease my (and other's) pain in case the RFC passes. I've tried using Andrea's own work and nikita's php-parser and good results quickly, but ended up switching due to the lack of whitespace support. Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Mike Benoit

11 years ago
Wouldn't this one change render all code in PEAR as broken? Is the gain really worth it? I understand PEAR is basically dead anyways, but for better or worse there is still a boat load of code that is being used from it (much of which lacks decent alternatives), and as other people mentioned such a BC break is likely to add years to the adoption of PHP7, which doesn't do anyone any good. On 01/15/2015 08:39 AM, Matteo Beccati wrote:
> Hi everyone, > >> I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If >> accepted, methods with the same name as their defining class will no >> longer be recognized as constructors. As noted in the RFC, there are >> already many situations where we do not recognize these methods as >> constructors, such as in namespaces and traits and when `function >> __construct` is also present. >> >> Andrea Faulds has kindly written a utility that identifies when a PHP >> 4 constructor is defined[2]. It does not automatically change the code >> for liability reasons. The utility PHPMD[3] can also detect this but >> has a false positive when `__construct` is also defined. > > I still think this (and other) BC breaks should be avoided if we want to > maximize PHP7 adoption, but I've started working on this: > > https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/970 > > which is a patch to php-cs-fixer that would be helpful to ease my (and > other's) pain in case the RFC passes. > > I've tried using Andrea's own work and nikita's php-parser and good > results quickly, but ended up switching due to the lack of whitespace > support. > > > Cheers
-- Mike

Ralf Lang

11 years ago
On 15.01.2015 21:35, Mike wrote:
> Wouldn't this one change render all code in PEAR as broken?
No.
-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Matteo Beccati

11 years ago
On 15/01/2015 22:16, Ralf Lang wrote:
> On 15.01.2015 21:35, Mike wrote: >> Wouldn't this one change render all code in PEAR as broken? > No.
Why not? PEAR uses PHP4-constructors almost everywhere. But PEAR can be fixed, I guess. Along with application using/extending it. The process can be automated, but still there's quite some work to do. Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Ralf Lang

11 years ago
On 16.01.2015 09:00, Matteo Beccati wrote:
> On 15/01/2015 22:16, Ralf Lang wrote: >> On 15.01.2015 21:35, Mike wrote: >>> Wouldn't this one change render all code in PEAR as broken? >> No. > > Why not? PEAR uses PHP4-constructors almost everywhere.
A lot of pear packages don't use custom constructors at all.
> But PEAR can be fixed, I guess. Along with application using/extending > it. The process can be automated, but still there's quite some work to do.
Yes, those parts worth fixing will and can be fixed. Other parts stay php4/5-only for use with legacy code.
-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Andrew Faulds

11 years ago
Hey Levi, Upon further thought, I’m not super-enthusiastic about this. As has been pointed out, it’s a pretty serious BC break, whether code can be automatically updated or not. PHP 4 constructors may be obsolete, but an awful lot of code uses them. A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. Thoughts?
-- Andrea Faulds http://ajf.me/

Levi Morrison

11 years ago
On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds <ajf@ajf.me> wrote:
> Hey Levi, > > Upon further thought, I’m not super-enthusiastic about this. As has been pointed out, it’s a pretty serious BC break, whether code can be automatically updated or not. PHP 4 constructors may be obsolete, but an awful lot of code uses them. > > A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working.
Possibly. The reality of my position is that I am unhappy about our current constructor situation. Having `__construct` and only half-heartedly supporting old-style constructors for the next several years (maybe ten?) does not sound good at all. Removing one of the constructors is a nicer end product than fully supporting both, in my opinion, which is why I proposed dropping it. I was hoping that a deprecation notice in 5.7 would be sufficient along with other standard migration tools and documentation, but since we have decided to not release 5.7 perhaps a deprecation would be better. At the same time I'm not thrilled about the amount of deprecation notices that could be generated if this is really as common as people seem to make it. I generally don't see these older constructors, but it seems when people have them they have *a lot* of them. I was okay with this in a theoretical 5.7 release to ease migration because it had a fixed lifespan of one release cycle but in version 7 it will stay for the duration of all PHP 7 releases. What do you guys think?

Andrew Faulds

11 years ago
Hey Levi,
> On 15 Jan 2015, at 17:16, Levi Morrison <levim@php.net> wrote: > > On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds <ajf@ajf.me> wrote: >> >> A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. > > Possibly. The reality of my position is that I am unhappy about our > current constructor situation. Having `__construct` and only > half-heartedly supporting old-style constructors for the next several > years (maybe ten?) does not sound good at all.
I agree, it doesn’t. Unfortunately, I’m not sure if we have much choice here.
> Removing one of the constructors is a nicer end product than fully > supporting both, in my opinion, which is why I proposed dropping it. I > was hoping that a deprecation notice in 5.7 would be sufficient along > with other standard migration tools and documentation, but since we > have decided to not release 5.7 perhaps a deprecation would be better. > > At the same time I'm not thrilled about the amount of deprecation > notices that could be generated if this is really as common as people > seem to make it. I generally don't see these older constructors, but > it seems when people have them they have *a lot* of them.
Yeah, I’m wondering about that. I imagine that a single request would probably result in a massive spew of E_DEPRECATEDs, and that’s not good. :/
> I was okay > with this in a theoretical 5.7 release to ease migration because it > had a fixed lifespan of one release cycle but in version 7 it will > stay for the duration of all PHP 7 releases. > > What do you guys think?
I wonder if we could hopefully get rid of them for PHP 8 or something, since it’s deprecated… but then, if we don’t get rid of them now, we might never. I’m not sure, really.
-- Andrea Faulds http://ajf.me/

Derick Rethans

11 years ago
On Thu, 15 Jan 2015, Levi Morrison wrote:
> On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds <ajf@ajf.me> wrote: > > > > Upon further thought, I’m not super-enthusiastic about this. As has > > been pointed out, it’s a pretty serious BC break, whether code can > > be automatically updated or not. PHP 4 constructors may be obsolete, > > but an awful lot of code uses them. > > > > A better solution, IMO, might be simply to add a deprecation notice. > > This would make it obvious during development if you’ve accidentally > > defined a PHP4 constructor, and would encourage migration away from > > them, but wouldn’t prevent existing code from working. > > Possibly. The reality of my position is that I am unhappy about our > current constructor situation. Having `__construct` and only > half-heartedly supporting old-style constructors for the next several > years (maybe ten?) does not sound good at all. > > Removing one of the constructors is a nicer end product than fully > supporting both, in my opinion, which is why I proposed dropping it.
Instead of just dropping it, which would likely generate odd bugs, declaring an old style constructor should *tell* you it's no longer working- perhaps with as strong of an error as an E_COMPILE_ERROR—atleast for PHP 7. Just removing it support would, IMO, be silly. cheers, Derick

Stelian Mocanita

11 years ago
Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development. Best, Stelian On Fri, Jan 16, 2015 at 12:28 PM, Derick Rethans <derick@php.net> wrote:

Florian Margaine

11 years ago
Hi Stelian, Stelian Mocanita writes:
> Hello everyone, > > Might I suggest community feedback on this one in a reddit thread? My guess > is that even though a lot of applications out there are still PHP 4 ctor > reliant, a very low percentage of these applications might be under active > development.
Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide.
> > Best, > Stelian >
Cheers,
-- Florian Margaine

Rowan Collins

11 years ago
Florian Margaine wrote on 16/01/2015 13:01:
> Hi Stelian, > > Stelian Mocanita writes: > >> Hello everyone, >> >> Might I suggest community feedback on this one in a reddit thread? My guess >> is that even though a lot of applications out there are still PHP 4 ctor >> reliant, a very low percentage of these applications might be under active >> development. > Not under active development doesn't mean that the application shouldn't > be able to upgrade PHP and enjoy the bug/security fixes or performance > improvements that new versions provide.
Upgrading to a new Major version is expected to require at least some checking and adaptation, so would require at least semi-active development status on the part of the project, IMHO.

Stelian Mocanita

11 years ago
Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian,
> > Stelian Mocanita writes: > > Hello everyone, >> >> Might I suggest community feedback on this one in a reddit thread? My >> guess >> is that even though a lot of applications out there are still PHP 4 ctor >> reliant, a very low percentage of these applications might be under active >> development. >> > Not under active development doesn't mean that the application shouldn't > be able to upgrade PHP and enjoy the bug/security fixes or performance > improvements that new versions provide.
Completely agree, but you get once in N years a chance to do some cleanup on the language. If people expect no BC breaks on major versions, when is the time for the cleanup? That's one thing. The other thing is that there's a flow in your logic. If you want the bug/security/performance fixes, it means you are already running latest stable and for some reason you completely ignored all of the deprecation warnings until now. I think we can both agree on this being a bit far-fetched. Not to mention that all the old ctor fatal errors can be fixed with an automated scripts that replaces the old ctors with the new ones. Stelian

Tony Marston

11 years ago
"Stelian Mocanita" wrote in message news:CAMc0WS5LpdVqF_5P8UiWBzuQc+maX+Shmmi8pZLgGRfOJ7aEmg@mail.gmail.com...
> >Florian Margaine wrote on 16/01/2015 13:01: > >Hi Stelian, >> >> Stelian Mocanita writes: >> >> Not under active development doesn't mean that the application shouldn't >> be able to upgrade PHP and enjoy the bug/security fixes or performance >> improvements that new versions provide.
I agree. If the core developers want each new release, with its bug fixes and security enhancements, to be adopted by the community then they should stop breaking BC for no good reason.
>Completely agree, but you get once in N years a chance to do some cleanup >on the language. If people expect no BC breaks on major versions, when is >the time for the cleanup?
It is one thing to remove functionality from the core if it a security issue or it causes bugs, but people's definitions of "clean" are many and varied, so using that as an excuse to break the language will not down well with those millions of website owners whose applications suddenly stop working after an upgrade. By "clean" it is obvious that you mean "style" as in "don't do it like that, do it like this". It is not up to the core developers to dictate style on the rest of the programmer community - you provide the basic tools, and it is up to the individual programmer to decide what functions to use in order to solve the problem at hand. Programming style is the prerogative of the individual programmer, or a team of programmers, and should never be dictated by any outside agency.
>That's one thing. The other thing is that there's a flow in your logic. If >you want the bug/security/performance fixes, it means you are already >running latest stable and for some reason you completely ignored all of the >deprecation warnings until now. I think we can both agree on this being a >bit far-fetched.
I am using PHP 5.6.4 with error_reporting=E_ALL and I am not seeing any messages regarding my use of PHP 4 constructors. They are also NOT marked as deprecated in the manual. If they are not marked as deprecated then you cannot suddenly remove them. Besides, what problem(s) would be solved by removing PHP 4 constructors? If there are no problems then removing them would not only NOT solve any problem it would actually create a HUGE problem for all those applications which still use them.
>Not to mention that all the old ctor fatal errors can be fixed with an >automated scripts that replaces the old ctors with the new ones. > >Stelian
-- Tony Marston

Pierre Joye

11 years ago
On Jan 17, 2015 5:58 PM, "Tony Marston" <TonyMarston@hotmail.com> wrote:
> > "Stelian Mocanita" wrote in message > news:CAMc0WS5LpdVqF_5P8UiWBzuQc+maX+Shmmi8pZLgGRfOJ7aEmg@mail.gmail.com... >> >> >> Florian Margaine wrote on 16/01/2015 13:01: >> >> Hi Stelian, >>> >>> >>> Stelian Mocanita writes: >>> >>> Not under active development doesn't mean that the application shouldn't >>> be able to upgrade PHP and enjoy the bug/security fixes or performance >>> improvements that new versions provide. > > > I agree. If the core developers want each new release, with its bug fixes > and security enhancements, to be adopted by the community then they should > stop breaking BC for no good reason.
Can wie stop using this argument pls? We are talking about something deprecated since 10 years, about the 1st major release in a decade, something we will use for the next 12-14 years. 5.x will be maintained as well for the next 3 years (plus distros LTS). We do not break BC since quite some time too in minor releases. Cheers, Pierre

Mike Willbanks

11 years ago
Hello Andrea, On Thu, Jan 15, 2015 at 10:55 AM, Andrea Faulds <ajf@ajf.me> wrote:
> Hey Levi, > > Upon further thought, I’m not super-enthusiastic about this. As has been > pointed out, it’s a pretty serious BC break, whether code can be > automatically updated or not. PHP 4 constructors may be obsolete, but an > awful lot of code uses them. > > A better solution, IMO, might be simply to add a deprecation notice. This > would make it obvious during development if you’ve accidentally defined a > PHP4 constructor, and would encourage migration away from them, but > wouldn’t prevent existing code from working. > > Thoughts? >
I would be against a deprecation notice here. In fact I think it should either be do nothing or remove them entirely. I know this thread has become out of control but as a user of PHP 3, 4 and 5; a framework developer; and a engineering executive I find that the PHP 4 style constructors to be an ignorance that I am forced to currently deal with. The amount of information in this post is vast and I don't feel I need to go into details. However, I support this proposal 100% as do I feel most of the open source community. Items that are still out there relying on PEAR and other packages should remain on PHP 5 or even less. We have better solutions now such as composer which has changed the ecosystems reliance on items such as PEAR. Developers that are relying on PEAR have other issues to date than simply what would happen with PHP 7 as not all PEAR packages work well with PHP 5 at this time especially the latest releases. PEAR is a thing that has come and gone. Legacy code that still remains with PHP 4 style constructors should upgrade to the latest. Language evolve and we need to keep pushing the bar forward. As a personal note, PHP has slowly been moving towards the background for certain applications for JavaScript (nodejs) and I feel for PHP to remain it's competitive market it needs to evolve more as a leading language. PHP was great about this between 3, 4 and 5. 7 must do the same thing otherwise I feel like it will lead to a slow death much like the perl of old. Regards, Mike

Pierre Joye

11 years ago
hi, On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison <levim@php.net> wrote:
> Dear Internals, > > I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If > accepted, methods with the same name as their defining class will no > longer be recognized as constructors. As noted in the RFC, there are > already many situations where we do not recognize these methods as > constructors, such as in namespaces and traits and when `function > __construct` is also present. > > Andrea Faulds has kindly written a utility that identifies when a PHP > 4 constructor is defined[2]. It does not automatically change the code > for liability reasons. The utility PHPMD[3] can also detect this but > has a false positive when `__construct` is also defined.
Not much to say about it as it is a taste/yes/no thing. Let wait the required period and move to vote, I do not see much needs to argue in a circular way forever :) Cheers,
-- Pierre @pierrejoye | http://www.libgd.org

Lester Caine

11 years ago
On 17/01/15 05:54, Pierre Joye wrote:
>> > Andrea Faulds has kindly written a utility that identifies when a PHP >> > 4 constructor is defined[2]. It does not automatically change the code >> > for liability reasons. The utility PHPMD[3] can also detect this but >> > has a false positive when `__construct` is also defined. > Not much to say about it as it is a taste/yes/no thing. > > Let wait the required period and move to vote, I do not see much needs > to argue in a circular way forever :)
Switching code to __construct is on my 5.2 to 5.4 upgrade crib sheet. I thought because e_strict moans about it? But on a quick scan I can't find a reference other than NOT flagging a warning when different parameters are used. Obviously this modernise is useful anyway, but where does it fit in the error handling currently?
-- 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