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

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

Dear Internals,

I am proposing an RFC1 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 defined2. It does not automatically change the code
for liability reasons. The utility PHPMD3 can also detect this but
has a false positive when __construct is also defined.

Cheers,
Levi Morrison

Hi all,

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

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! :)

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

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.

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

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?

Hello Andrea,

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

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

On Thu, Nov 20, 2014 at 5:43 PM, Johannes Schlüter
johannes@schlueters.de 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

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

On Thu, Nov 20, 2014 at 2:43 AM, Johannes Schlüter
johannes@schlueters.de 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?

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/

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