Hi Levi,
On Sat, Feb 7, 2015 at 7:05 AM, Levi Morrison morrison.l...@gmail.com
wrote:
I have updated the RFC for removing PHP 4 constructors[1]. Notably, I
have pushed off the removal to PHP 8, and instead only deprecate them
in PHP 7. The rationale is that eventual consistency in this matter
On Sat, Feb 7, 2015 at 2:32 PM, Matteo Beccati p...@beccati.com wrote:
Hi Levi,
I have updated the RFC for removing PHP 4 constructors[1]. Notably, I
have pushed off the removal to PHP 8, and instead only deprecate them
in PHP 7. The rationale is that eventual consistency in this matter is
Hi Levi,
I have updated the RFC for removing PHP 4 constructors[1]. Notably, I
have pushed off the removal to PHP 8, and instead only deprecate them
in PHP 7. The rationale is that eventual consistency in this matter is
good enough for now, and going slow may help avoid a Python 2 vs 3
type
Dear Internals,
I have updated the RFC for removing PHP 4 constructors[1]. Notably, I
have pushed off the removal to PHP 8, and instead only deprecate them
in PHP 7. The rationale is that eventual consistency in this matter is
good enough for now, and going slow may help avoid a Python 2 vs 3
2015-01-21 19:21 GMT+02:00 Tony Marston tonymars...@hotmail.com:
Kristopher wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+
tmatgqrb7yqeips11...@mail.gmail.com...
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com
wrote:
You are totally missing the point. It is
2015-01-22 15:22 GMT+02:00 Arvids Godjuks arvids.godj...@gmail.com:
2015-01-21 19:21 GMT+02:00 Tony Marston tonymars...@hotmail.com:
Kristopher wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+
tmatgqrb7yqeips11...@mail.gmail.com...
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston
Arvids Godjuks wrote in message
news:CAL0xaBFDOP0402T06DJLjbmv6CgsS+xcnY69=szrzts5br5...@mail.gmail.com...
2015-01-22 15:22 GMT+02:00 Arvids Godjuks arvids.godj...@gmail.com:
2015-01-21 19:21 GMT+02:00 Tony Marston tonymars...@hotmail.com:
Kristopher wrote in message
On Wed, Jan 21, 2015 at 12:21 PM, Tony Marston tonymars...@hotmail.com
wrote:
Because I would rather fight for valid principles than give in. To quote
Emiliano Zapata It is better to die on your feet than live on your knees.
I don't think constructors are what he had in mind.
Kristopher wrote in message
news:caf9u7z_bldusnq7c0mvtoxyjpqopa+tmatgqrb7yqeips11...@mail.gmail.com...
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com
wrote:
You are totally missing the point. It is the principle of having to spent
unknown quantities of time in
On Jan 22, 2015 12:21 AM, Tony Marston tonymars...@hotmail.com wrote:
Kristopher wrote in message
news:caf9u7z_bldusnq7c0mvtoxyjpqopa+tmatgqrb7yqeips11...@mail.gmail.com...
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com
wrote:
You are totally missing the point. It
Kristopher wrote in message
news:CAF9U7z-bkYRDwAL8CA4_=1dhorl0evp_mzwf6qwqscwdf7n...@mail.gmail.com...
On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston tonymars...@hotmail.com
wrote:
@tony: What's really interesting is that all this time you've spent arguing
could have been used to update your
François Laupretre wrote in message
news:018d01d03501$c0a877d0$41f96770$@tekwire.net...
De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part
I'm happy to update the manual, but I think I'd want more of a
consensus (not necessarily a formal RFC, but at least a straw poll)
for
Ralf Lang wrote in message news:54beb145.7030...@b1-systems.de...
#1 and #2 may be considered to be genuine improvements by the user
community, but #3 most certainly will not. It does not matter how you
try to dress it up, forcing your end users to jump through hoops before
they can upgrade is
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com
wrote:
You are totally missing the point. It is the principle of having to spent
unknown quantities of time in refactoring my code for nothing more than a
frivolous and unnecessary break in BC. It does not fi a bug or a
Rowan Collins wrote in message news:54bd4d98.80...@gmail.com...
Tony Marston wrote on 19/01/2015 16:24:
Rowan Collins wrote in message news:54bd240a.7050...@gmail.com...
Tony Marston wrote on 19/01/2015 15:01:
The aim should be to eliminate customer grievances as much as possible
and not
On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston tonymars...@hotmail.com
wrote:
@tony: What's really interesting is that all this time you've spent arguing
could have been used to update your code and make this no longer an issue
for you.
@everyone: Would an RFC be necessary to update the PHP
On 20 January 2015 at 07:09, Kristopher kristopherwil...@gmail.com wrote:
@everyone: Would an RFC be necessary to update the PHP manual to actually
recommend the PHP 5 constructors and recommend against using the PHP 4
style constructors, using very explicit language? If not, should this
De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part
I'm happy to update the manual, but I think I'd want more of a
consensus (not necessarily a formal RFC, but at least a straw poll)
for soft deprecation (to reuse the term we used for mysql_* before
it started generating
#1 and #2 may be considered to be genuine improvements by the user
community, but #3 most certainly will not. It does not matter how you
try to dress it up, forcing your end users to jump through hoops before
they can upgrade is a customer relations disaster.
PHP and other scripting
Hello Andrea,
On Thu, Jan 15, 2015 at 10:55 AM, Andrea Faulds a...@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
Andrey Andreev wrote in message
news:caphkizzytddn2b_e84ygk3xhiudgh-m0jtqdlo85cy3pc8c...@mail.gmail.com...
On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston tonymars...@hotmail.com
wrote:
snip
Talk about ignorance ... you've ignored the new style of coding for a
decade and don't want to be
Hi,
On Mon, Jan 19, 2015 at 5:01 PM, Tony Marston tonymars...@hotmail.com wrote:
But the only benefits with the removal of old features is a smaller code
base for the core developers. The only benefit which is experienced in
userland is that applications which have run for over a decade
Rowan Collins wrote in message news:54bce8f5.5080...@gmail.com...
Tony Marston wrote on 19/01/2015 10:37:
Rowan Collins wrote in message
news:calkijkr3os6ta55rjlq61o1+on-s3j8xfzmhjvqfxozlzwt...@mail.gmail.com...
snip
But the only benefits with the removal of old features is a smaller
Tony Marston wrote on 19/01/2015 15:01:
The aim should be to eliminate customer grievances as much as possible
and not to simply ignore them.
I am not ignoring the grievances, and have repeatedly said that I am not
sure whether or not the change is justified in this case.
You, however, are
On 19 Jan 2015, at 10:05, Tony Marston tonymars...@hotmail.com wrote:
Marcio Almada wrote in message
news:caoshv+uho3ovs-beqmdjomz4sdwoyjn7znmcqmt8byynugq...@mail.gmail.com...
Perhaps there should be a new rule which says that invoking a constructor
with anything other than new or
Marcio Almada wrote in message
news:caoshv+uho3ovs-beqmdjomz4sdwoyjn7znmcqmt8byynugq...@mail.gmail.com...
Perhaps there should be a new rule which says that invoking a constructor
with anything other than new or parent::__contruct()
should be illegal, in which case this situation would
Tony Marston wrote on 19/01/2015 10:37:
Rowan Collins wrote in message
news:calkijkr3os6ta55rjlq61o1+on-s3j8xfzmhjvqfxozlzwt...@mail.gmail.com...
On 18 January 2015 at 12:23, Tony Marston tonymars...@hotmail.com
wrote:
Rowan Collins wrote in message news:54baba93.9070...@gmail.com...
Rowan Collins wrote in message news:54bd240a.7050...@gmail.com...
Tony Marston wrote on 19/01/2015 15:01:
The aim should be to eliminate customer grievances as much as possible
and not to simply ignore them.
I am not ignoring the grievances, and have repeatedly said that I am not
sure
Am 19.01.2015 um 17:42 schrieb Tony Marston:
has already been pointed out that there are a large number of PEAR
libraries which were written with PHP 4 constructors and have never been
updated.
So? If that code is still valuable to people they will update it. Or
rather would have updated it
On 19/01/15 16:45, Sebastian Bergmann wrote:
has already been pointed out that there are a large number of PEAR
libraries which were written with PHP 4 constructors and have never been
updated.
So? If that code is still valuable to people they will update it. Or
rather would have updated
Andrey Andreev wrote in message
news:CAPhkiZz=gYDbHngV+gHhTgW415_KxoCU-31OiW=dxPkPg=t...@mail.gmail.com...
Hi,
On Mon, Jan 19, 2015 at 5:01 PM, Tony Marston tonymars...@hotmail.com
wrote:
But the only benefits with the removal of old features is a smaller
code
base for the core developers.
On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston tonymars...@hotmail.com wrote:
Ah, so you admit there may be benefits? Again, I do not say that those
benefits are definitely enough to justify the change in this case, but
they
are real, and I would like you to stop dismissing them.
There is a
Tony Marston wrote on 19/01/2015 16:24:
Rowan Collins wrote in message news:54bd240a.7050...@gmail.com...
Tony Marston wrote on 19/01/2015 15:01:
The aim should be to eliminate customer grievances as much as
possible and not to simply ignore them.
I am not ignoring the grievances, and have
Levi Morrison wrote in message
news:cafmt4nopoeohga+uorsjrxosrh4k3eid96-jmmoqghct8uj...@mail.gmail.com...
On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth tr...@proposaltech.com wrote:
On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote:
snip
According to the PHP.net documentation on
Rowan Collins wrote in message news:54baba93.9070...@gmail.com...
On 17/01/2015 18:33, Todd Ruth wrote:
As already mentioned I think as an end result we shouldn't have two
ways to define constructors. Given that PHP already prefers the
new-style constructors I've proposed that we work towards
Andrea Faulds wrote in message
news:d554c8b8-0bfb-44f7-b23e-8bfc12ae2...@ajf.me...
Hey Rowan,
On 17 Jan 2015, at 19:40, Rowan Collins rowan.coll...@gmail.com wrote:
On 17/01/2015 18:33, Todd Ruth wrote:
snip
I don't think using __construct over named-method for constructors really
has
On 18 January 2015 at 12:23, Tony Marston tonymars...@hotmail.com wrote:
Rowan Collins wrote in message news:54baba93.9070...@gmail.com...
On 17/01/2015 18:33, Todd Ruth wrote:
As already mentioned I think as an end result we shouldn't have two
ways to define constructors. Given that PHP
Perhaps there should be a new rule which says that invoking a constructor
with anything other than new or parent::__contruct()
should be illegal, in which case this situation would generate an error.
Now this would break a lot of code that $obj-__construct(); or
$this-__construct(); And I've
Hi,
Please don't construe the willingness to add E_STRICTs with agreement
that such code should be forcibly eliminated. If there were a fully
automated tool to bring code into compliance, I would feel a lot better
about such changes, but even then, many of us would be applying that
tool to
Levi Morrison wrote in message
news:CAFMT4NrH+=6B4=kvyrmw1oc0n-_onndjawk0xzcxdvnv_pn...@mail.gmail.com...
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.
That is the point - PHP 4
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
Stelian Mocanita wrote in message
news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@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
On Jan 17, 2015 5:58 PM, Tony Marston tonymars...@hotmail.com wrote:
Stelian Mocanita wrote in message
news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com...
Florian Margaine wrote on 16/01/2015 13:01:
Hi Stelian,
Stelian Mocanita writes:
Not under active
On Jan 17, 2015 5:58 PM, Tony Marston tonymars...@hotmail.com wrote:
Stelian Mocanita wrote in message
news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com...
Florian Margaine wrote on 16/01/2015 13:01:
Hi Stelian,
Stelian Mocanita writes:
Not under active
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
Hi Pierre!
On 17/01/15 08:02, Pierre Joye wrote:
On Jan 17, 2015 5:58 PM, Tony Marston tonymars...@hotmail.com wrote:
Stelian Mocanita wrote in message
news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com...
Florian Margaine wrote on 16/01/2015 13:01:
Hi Stelian,
On 17 January 2015 at 13:38, César Rodas ce...@rodas.me wrote:
Hi Pierre!
On 17/01/15 08:02, Pierre Joye wrote:
On Jan 17, 2015 5:58 PM, Tony Marston tonymars...@hotmail.com wrote:
Stelian Mocanita wrote in message
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.
That is the point - PHP 4 constructors have NOT been marked as deprecated in
the manual, and they produce no warnings at runtime.
If they have
On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote:
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.
That is the point - PHP 4 constructors have NOT been marked as deprecated in
the
Hey Rowan,
On 17 Jan 2015, at 19:40, Rowan Collins rowan.coll...@gmail.com wrote:
On 17/01/2015 18:33, Todd Ruth wrote:
As already mentioned I think as an end result we shouldn't have two
ways to define constructors. Given that PHP already prefers the
new-style constructors I've proposed
On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth tr...@proposaltech.com wrote:
On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote:
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.
That is
On 17/01/2015 18:33, Todd Ruth wrote:
As already mentioned I think as an end result we shouldn't have two
ways to define constructors. Given that PHP already prefers the
new-style constructors I've proposed that we work towards dropping the
old-style, it's just down to a matter of how.
I've
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
On Thu, 15 Jan 2015, Levi Morrison wrote:
On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@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
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
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.
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
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
hi,
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@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
On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@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
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
Hey Levi,
On 15 Jan 2015, at 17:16, Levi Morrison le...@php.net wrote:
On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@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
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
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
On 15 January 2015 at 17:35, Pierre Joye pierre@gmail.com wrote:
On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote:
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote:
On Fri, Jan 16, 2015 at 8:14 AM, Adam Harvey ahar...@php.net wrote:
On 15 January 2015 at 17:35, Pierre Joye pierre@gmail.com wrote:
On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote:
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
On Tue, Nov 18, 2014 at 3:11
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: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner /
On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote:
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote:
https://wiki.php.net/rfc/remove_php4_constructors
Entirely +1 on removing them in PHP7.
On Fri, Nov 21, 2014 at 11:20 AM, Levi Morrison le...@php.net wrote:
BTW, old constructor has problem with traits (is this mentioned already?)
http://3v4l.org/KZKXo
I suppose nobody is using this side effect in production code, but
there would be number of users who are confused by this
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@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
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@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
On 20/11/14 21:29, Rowan Collins wrote:
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
Lester Caine wrote on 21/11/2014 09:49:
I know I sound like a broken record, but this is EXACTLY the same
problem as e_strict! It is all very well saying old code can still run
if you hide the the warnings and ERRORS, but you have to spend the time
fixing each and every warning simply to ensure
On 21/11/14 11:31, Rowan Collins wrote:
I know I sound like a broken record, but this is EXACTLY the same
problem as e_strict! It is all very well saying old code can still run
if you hide the the warnings and ERRORS, but you have to spend the time
fixing each and every warning simply to
Zitat von Lester Caine les...@lsces.co.uk:
On 21/11/14 11:31, Rowan Collins wrote:
I know I sound like a broken record, but this is EXACTLY the same
problem as e_strict! It is all very well saying old code can still run
if you hide the the warnings and ERRORS, but you have to spend the time
Hi,
I still don't get get what problem this RFC is actually going to solve?
I don't see a problem. Yes, PHP4 constructors are are old and should no
longer be used. But there is no problem still supporting them. Raise an
E_DEPRECATED for those, and be done with it.
+1
I can accept BC-breaks
On 21/11/14 12:36, Jan Schneider wrote:
Zitat von Lester Caine les...@lsces.co.uk:
On 21/11/14 11:31, Rowan Collins wrote:
I know I sound like a broken record, but this is EXACTLY the same
problem as e_strict! It is all very well saying old code can still run
if you hide the the warnings
Lester Caine wrote on 21/11/2014 13:27:
No - There have been several threads on deprecating things that are
currently 'hidden' by e_strict. The confusion is created by having two
incompatible styles of coding, and unless one brings the 'non-e_strict'
code in to line with current practices it
On 21/11/14 14:15, Rowan Collins wrote:
Lester Caine wrote on 21/11/2014 13:27:
No - There have been several threads on deprecating things that are
currently 'hidden' by e_strict. The confusion is created by having two
incompatible styles of coding, and unless one brings the 'non-e_strict'
Hi,
On Fri, 2014-11-21 at 16:48 +0900, Yasuo Ohgaki wrote:
How about use INI until PHP8?
No. php.ini needs less settings not more. Especially not for language
things. This makes a mess for creating portable code. ze1 compat mode
was a fault as were other ini settings we had. Let's not go
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@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
Johannes Schlüter wrote on 21/11/2014 16:13:
Hi,
On Fri, 2014-11-21 at 16:48 +0900, Yasuo Ohgaki wrote:
How about use INI until PHP8?
No. php.ini needs less settings not more. Especially not for language
things. This makes a mess for creating portable code. ze1 compat mode
was a fault as
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
BTW, old constructor has problem with traits (is this mentioned already?)
http://3v4l.org/KZKXo
I suppose nobody is using this side effect in production code, but
there would be number of users who are confused by this behavior.
If I remember the source code correctly, this should be
On Wed, 2014-11-19 at 14:33 +, 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
On Thu, Nov 20, 2014 at 5:43 PM, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2014-11-19 at 14:33 +, 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
Hi,
On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui larue...@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
On Thu, Nov 20, 2014 at 10:32 PM, Andrey Andreev n...@devilix.net wrote:
Hi,
On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui larue...@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
On Thu, Nov 20, 2014 at 2:43 AM, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2014-11-19 at 14:33 +, 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
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?
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
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
On 20 November 2014 20:54:00 GMT, Levi Morrison le...@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
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
Hi all,
On Fri, Nov 21, 2014 at 6:39 AM, Johannes Schlüter johan...@schlueters.de
wrote:
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
On Wed, Nov 19, 2014 at 5:15 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison le...@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
Le Wed Nov 19 2014 at 9:31:50 AM, Julien Pauli jpa...@php.net a écrit :
On Wed, Nov 19, 2014 at 5:15 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison le...@php.net wrote:
I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@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
-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
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
1 - 100 of 114 matches
Mail list logo
