Hi Levi,
On Sat, Feb 7, 2015 at 7:05 AM, Levi Morrison
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 is
> good enough for
On Sat, Feb 7, 2015 at 2:32 PM, Matteo Beccati 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
>> good en
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 disa
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
type
"Arvids Godjuks" wrote in message
news:CAL0xaBFDOP0402T06DJLjbmv6CgsS+xcnY69=szrzts5br5...@mail.gmail.com...
2015-01-22 15:22 GMT+02:00 Arvids Godjuks :
2015-01-21 19:21 GMT+02:00 Tony Marston :
"Kristopher" wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+
tmatgqrb7yqeips11...@mail.gm
2015-01-22 15:22 GMT+02:00 Arvids Godjuks :
> 2015-01-21 19:21 GMT+02:00 Tony Marston :
>
>> "Kristopher" wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+
>> tmatgqrb7yqeips11...@mail.gmail.com...
>>
>>>
>>> On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston
>>> wrote:
>>>
>>>
You are total
2015-01-21 19:21 GMT+02:00 Tony Marston :
> "Kristopher" wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+
> tmatgqrb7yqeips11...@mail.gmail.com...
>
>>
>> On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston
>> wrote:
>>
>>
>>> You are totally missing the point. It is the principle of having to sp
"Pierre Joye" wrote in message
news:caezptu6rlmncdvgbr1cd4hxa0syt0dxs3kvjfdpuwiwmx_l...@mail.gmail.com...
On Jan 22, 2015 12:21 AM, "Tony Marston" wrote:
"Kristopher" wrote in message
news:caf9u7z_bldusnq7c0mvtoxyjpqopa+tmatgqrb7yqeips11...@mail.gmail.com...
On Wed, Jan 21, 2015 at 9:5
On Jan 22, 2015 12:21 AM, "Tony Marston" wrote:
>
> "Kristopher" wrote in message
news:caf9u7z_bldusnq7c0mvtoxyjpqopa+tmatgqrb7yqeips11...@mail.gmail.com...
>
>>
>> On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston
>> wrote:
>>
>>>
>>> You are totally missing the point. It is the principle of having
On Wed, Jan 21, 2015 at 12:21 PM, Tony Marston
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
wrote:
You are totally missing the point. It is the principle of having to spent
unknown quantities of time in refactoring my code for nothi
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston
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 security
> issue, there
"Kristopher" wrote in message
news:CAF9U7z-bkYRDwAL8CA4_=1dhorl0evp_mzwf6qwqscwdf7n...@mail.gmail.com...
On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston
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 l
"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 i
""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
> 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 generatin
>
> #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 lan
On 20 January 2015 at 07:09, Kristopher 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
> change be made, regardless o
On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston
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 manual to actually
recommend
"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 n
Hello Andrea,
On Thu, Jan 15, 2015 at 10:55 AM, Andrea Faulds 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
"Andrey Andreev" wrote in message
news:caphkizzytddn2b_e84ygk3xhiudgh-m0jtqdlo85cy3pc8c...@mail.gmail.com...
On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston
wrote:
<>
Talk about ignorance ... you've ignored the new style of coding for a
decade and don't want to be bothered to adapt to it
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 hav
On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston 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
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
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 i
"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
wrote:
But the only benefits with the removal of old features is a smaller
code
base for the core developers. The only "benefit" whi
"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 whe
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
Hi,
On Mon, Jan 19, 2015 at 5:01 PM, Tony Marston 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 suddenly stop
>>> w
"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...
<>
But the only benefits with the removal of old features is a smaller c
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
wrote:
"Rowan Collins" wrote in message news:54baba93.9070...@gmail.com...
This problem is partly
"Andrea Faulds" wrote in message
news:3c77d1e5-acf1-442d-bc84-59e49efd6...@ajf.me...
On 19 Jan 2015, at 10:05, Tony Marston wrote:
"Marcio Almada" wrote in message
news:caoshv+uho3ovs-beqmdjomz4sdwoyjn7znmcqmt8byynugq...@mail.gmail.com...
Perhaps there should be a new rule which says th
"Rowan Collins" wrote in message
news:calkijkr3os6ta55rjlq61o1+on-s3j8xfzmhjvqfxozlzwt...@mail.gmail.com...
On 18 January 2015 at 12:23, Tony Marston wrote:
"Rowan Collins" wrote in message news:54baba93.9070...@gmail.com...
On 17/01/2015 18:33, Todd Ruth wrote:
<>
This problem is p
> On 19 Jan 2015, at 10:05, Tony Marston 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 "parent::__
"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
On 18 January 2015 at 12:23, Tony Marston 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 alread
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
> 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();
"Andrea Faulds" wrote in message
news:d554c8b8-0bfb-44f7-b23e-8bfc12ae2...@ajf.me...
Hey Rowan,
On 17 Jan 2015, at 19:40, Rowan Collins wrote:
On 17/01/2015 18:33, Todd Ruth wrote:
<>
I don't think using __construct over named-method for constructors really
has anything to do with "OOP
"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 towa
"Levi Morrison" wrote in message
news:cafmt4nopoeohga+uorsjrxosrh4k3eid96-jmmoqghct8uj...@mail.gmail.com...
On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth wrote:
On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote:
<>
According to the PHP.net documentation on
E_STRICT(http://php.net/manua
"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 constructo
Hey Rowan,
> On 17 Jan 2015, at 19:40, Rowan Collins 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 that we wor
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 b
On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth 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 the poi
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
>> 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 t
On 17 January 2015 at 13:38, César Rodas wrote:
> Hi Pierre!
>
> On 17/01/15 08:02, Pierre Joye wrote:
> > On Jan 17, 2015 5:58 PM, "Tony Marston" wrote:
> >>
> >> "Stelian Mocanita" wrote in message
> >> news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com.
> ..
> >>>
> >>>
Hi Pierre!
On 17/01/15 08:02, Pierre Joye wrote:
> On Jan 17, 2015 5:58 PM, "Tony Marston" 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 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 constru
On Jan 17, 2015 5:58 PM, "Tony Marston" 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 development doesn't mean tha
On Jan 17, 2015 5:58 PM, "Tony Marston" 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
"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 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 `__co
hi,
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison 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
> alrea
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 percentag
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 applica
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
> developm
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
On Thu, 15 Jan 2015, Levi Morrison wrote:
> On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds 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 constru
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 automa
On Fri, Jan 16, 2015 at 8:14 AM, Adam Harvey wrote:
> On 15 January 2015 at 17:35, Pierre Joye wrote:
>>
>> On Nov 26, 2014 1:39 AM, "Adam Harvey" wrote:
>>>
>>> On 25 November 2014 at 10:36, Sara Golemon wrote:
>>> > On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison wrote:
>>> >> https://wiki.ph
On 15 January 2015 at 17:35, Pierre Joye wrote:
>
> On Nov 26, 2014 1:39 AM, "Adam Harvey" wrote:
>>
>> On 25 November 2014 at 10:36, Sara Golemon wrote:
>> > On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison wrote:
>> >> https://wiki.php.net/rfc/remove_php4_constructors
>> >>
>> > Entirely +1 on
On Nov 26, 2014 1:39 AM, "Adam Harvey" wrote:
>
> On 25 November 2014 at 10:36, Sara Golemon wrote:
> > On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison wrote:
> >> https://wiki.php.net/rfc/remove_php4_constructors
> >>
> > Entirely +1 on removing them in PHP7.
> >
> > Did we decide on having a 5.
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 / Unternehmen
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 s
Hey Levi,
> On 15 Jan 2015, at 17:16, Levi Morrison wrote:
>
> On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds 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 constructo
On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds 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 lo
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 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
constructor
On 25 November 2014 at 10:36, Sara Golemon wrote:
> On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison 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
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison 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,
On Fri, Nov 21, 2014 at 11:20 AM, Levi Morrison 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 behavi
> 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 c
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 githu
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 we
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison 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 m
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 the
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_stric
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 crea
On 21/11/14 12:36, Jan Schneider wrote:
>
> Zitat von Lester Caine :
>
>> 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 an
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 if
Zitat von Lester Caine :
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 ever
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 t
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 t
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 ver
Hi all,
On Fri, Nov 21, 2014 at 6:39 AM, Johannes Schlüter
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 for this and
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 severa
On 20 November 2014 20:54:00 GMT, Levi Morrison 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
>> 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
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
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
> cal
On Thu, Nov 20, 2014 at 2:43 AM, Johannes Schlüter
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 would get
On Thu, Nov 20, 2014 at 10:32 PM, Andrey Andreev wrote:
> Hi,
>
> On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui 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 feat
Hi,
On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui 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' co
On Thu, Nov 20, 2014 at 5:43 PM, Johannes Schlüter
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 would get
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 b
On Wed, Nov 19, 2014 at 4:10 PM, Andrea Faulds wrote:
>
>> On 19 Nov 2014, at 15:07, Alain Williams 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
On Wed, Nov 19, 2014 at 3:33 PM, Alain Williams wrote:
> On Wed, Nov 19, 2014 at 02:27:12PM +, 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 wh
1 - 100 of 117 matches
Mail list logo
