Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Arvids, On Thu, Apr 30, 2015 at 3:40 PM, Arvids Godjuks wrote: > Stop trying to fix clever idiots from shooting themselves in the foot. The >> standard result from these actions is to make life a pain for regular or >> better programmers while only adding mild speed bumps to those clever >> i

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Walter Parker
On Wed, Apr 29, 2015 at 11:47 PM, Yasuo Ohgaki wrote: > Hi Walter, > > On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker wrote: > >> And that is relevant how? How many Android phone run PHP applications? > > > Search web for IoT devices that can run PHP. > > Regards, > > -- > Yasuo Ohgaki > yohg...

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Stanislav Malyshev
Hi! > Unfortunately, not all users does this and new PHP type hint opens new hole > that security researchers and attackers are interested in. I am sorry, but you still brought no proof at all that there are any security implications. Without such proof, these claims are baseless, so I intend to

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Walter Parker
On Wed, Apr 29, 2015 at 11:40 PM, Arvids Godjuks wrote: > Stop trying to fix clever idiots from shooting themselves in the foot. The >> standard result from these actions is to make life a pain for regular or >> better programmers while only adding mild speed bumps to those clever >> idiots. >> >

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Walter, On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker wrote: > And that is relevant how? How many Android phone run PHP applications? Search web for IoT devices that can run PHP. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Stas, On Thu, Apr 30, 2015 at 2:42 PM, Stanislav Malyshev wrote: > > "int" Cast is bad. Incorrect "int" type hint worse as it could trigger > DoS. > > I do not see any potential for DoS here. Trying to assign security > implications so it looks like disagreeing with you jeopardizes security >

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Arvids Godjuks
> > Stop trying to fix clever idiots from shooting themselves in the foot. The > standard result from these actions is to make life a pain for regular or > better programmers while only adding mild speed bumps to those clever > idiots. > > Things like a numeric type will only encourage the clever i

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Walter Parker
On Wed, Apr 29, 2015 at 10:50 PM, Yasuo Ohgaki wrote: > Ryan, > > On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas wrote: > > > On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki > wrote: > > > >> Hi Rowan, > >> > >> On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki > >> wrote: > >> > >> > > >> >> A fata

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Walter Parker
On Wed, Apr 29, 2015 at 10:42 PM, Stanislav Malyshev wrote: > Hi! > > > "int" Cast is bad. Incorrect "int" type hint worse as it could trigger > DoS. > > I do not see any potential for DoS here. Trying to assign security > implications so it looks like disagreeing with you jeopardizes security >

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Ryan, On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas wrote: > On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki wrote: > >> Hi Rowan, >> >> On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki >> wrote: >> >> > >> >> A fatal error wouldn't constitute a DoS vulnerability, would it? >> >> Attack

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Stanislav Malyshev
Hi! > "int" Cast is bad. Incorrect "int" type hint worse as it could trigger DoS. I do not see any potential for DoS here. Trying to assign security implications so it looks like disagreeing with you jeopardizes security is not a good idea. If your code accepts non-numeric data and puts it to fun

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Stas, On Thu, Apr 30, 2015 at 12:05 PM, Stanislav Malyshev wrote: > > How many of us are expected that > > > > mydb_find_by_id(INT_MAX+1); > > Note: INT_MAX+1 is pseudo integer string value. > > > > fails with fatal error? I guess it's not many. > > I'm not sure what is the meaning of "INT_MA

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Walter Parker
On Wed, Apr 29, 2015 at 9:33 PM, Yasuo Ohgaki wrote: > Hi Walter, > > On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker wrote: > >> Are you asking to have both the 32 and 64 bit versions of PHP fully map >> to the type system in SQLite? The type system in SQLite appears to have >> been setup to ma

Re: [PHP-DEV] [VOTE] Exceptions in the engine

2015-04-29 Thread Sebastian Bergmann
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev: > I like the idea, however we do have the deadline and the > deadline has been passed. So I wonder if we can't keep it for 7.1 That means introducing a change in 7.0, changing it and deprecating part of it in 7.1, and removing said part in 7.2/8

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Dan, On Thu, Apr 30, 2015 at 12:02 PM, Dan Ackroyd wrote: > On 30 April 2015 at 02:17, Yasuo Ohgaki wrote: > > Current PHP: Search query failure. > > New PHP type hint: Fatal error because foreign key is out of PHP int > range. > > There may be some confusion; NikiC is still doing some work to

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Walter, On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker wrote: > Are you asking to have both the 32 and 64 bit versions of PHP fully map to > the type system in SQLite? The type system in SQLite appears to have been > setup to map to programming language that lots of types (modern C, C++, > m

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Ryan Pallas
On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki wrote: > Hi Rowan, > > On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki wrote: > > > > >> A fatal error wouldn't constitute a DoS vulnerability, would it? > > Attacker may inject huge ID value and/or they may simply access > >>> web sites t

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Stanislav Malyshev
Hi! > How many of us are expected that > > mydb_find_by_id(INT_MAX+1); > Note: INT_MAX+1 is pseudo integer string value. > > fails with fatal error? I guess it's not many. I'm not sure what is the meaning of "INT_MAX+1 is pseudo integer string value" - if it fits the integer, it's the integer,

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Dan Ackroyd
On 30 April 2015 at 02:17, Yasuo Ohgaki wrote: > Current PHP: Search query failure. > New PHP type hint: Fatal error because foreign key is out of PHP int range. There may be some confusion; NikiC is still doing some work to tidy up the EngineExceptions. When that is finished passing a variable o

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Walter Parker
On Wed, Apr 29, 2015 at 7:37 PM, Yasuo Ohgaki wrote: > Hi Rowan, > > On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki wrote: > > > > >> A fatal error wouldn't constitute a DoS vulnerability, would it? > > Attacker may inject huge ID value and/or they may simply access > >>> web sites t

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Rowan, On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki wrote: > >> A fatal error wouldn't constitute a DoS vulnerability, would it? Attacker may inject huge ID value and/or they may simply access >>> web sites to reach 2 billion limit, for example. >>> >> >> That's not a DoS vector

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Rowan, On Thu, Apr 30, 2015 at 11:00 AM, Rowan Collins wrote: > On 30/04/2015 02:24, Yasuo Ohgaki wrote: > >> "Type hints" have never been hints. The wording is a misnomer. Try to >>> pass an int to a parameter declared as array, for instance. >>> >>> I understand how it worked and how it

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Rowan Collins
On 30/04/2015 02:24, Yasuo Ohgaki wrote: "Type hints" have never been hints. The wording is a misnomer. Try to pass an int to a parameter declared as array, for instance. I understand how it worked and how it will. "hint" sounds a little misleading. Since we named it already, we may follow th

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Christoph, On Thu, Apr 30, 2015 at 9:27 AM, Christoph Becker wrote: > > On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev > > > wrote: > > > >> PHP types are not machine native types. But yes, it forces PHP type - > >> that's why it is *type* check. > > > > Type hint is better to stay as "

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Stas, On Thu, Apr 30, 2015 at 9:20 AM, Stanislav Malyshev wrote: > > If you need to force to map value to PHP type, you have "strict" mode. > > "Weak" > > mode is just too strict currently even if PHP handled int/float/string as > > "integer"/"float" including invalid values traditionally. >

Re: [PHP-DEV] [VOTE] Exceptions in the engine

2015-04-29 Thread Stanislav Malyshev
Hi! >> The vote for this missed the boat for the PHP 7 deadline. However, if >> we really want to do this we should do it in PHP 7 or not at all (at >> least not for a long time) due to BC breaks. >> >> Thoughts? It's kind of hard to recover the context here, but I assume it's https://wiki.php.ne

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Stanislav Malyshev
Hi! > we asked for feedbacks on the matter [1] [2], stating from the very > beginning that, to our understanding, it wasn't a feature but code > gardening. I think introducing new engine APIs, to be used by extensions, is not something that should be taken lightly as mere refactoring. If the exte

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Christoph Becker
Yasuo Ohgaki wrote: > On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev > wrote: > >> PHP types are not machine native types. But yes, it forces PHP type - >> that's why it is *type* check. > > Type hint is better to stay as "hint" under weak mode. IMO. "Type hints" have never been hints. T

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Stanislav Malyshev
Hi! > You can cast your vote on the Wiki [1] and the according patch is > available as a Pull Request [2]. > > Vote will be open for two weeks, counting from today. > I think the idea of this RFC is nice but it needs a bit more work to make it really good and successful. See some of the notes b

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Nathan, On Thu, Apr 30, 2015 at 6:41 AM, Nathan Bruer wrote: > This has been a big issue that I have ran into many times in the past for > large framework projects, instead of building it out with "strict" types > like: int, float, string, exc... It makes more sense to allow a user to > defin

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Stanislav Malyshev
Hi! > If you need to force to map value to PHP type, you have "strict" mode. > "Weak" > mode is just too strict currently even if PHP handled int/float/string as > "integer"/"float" including invalid values traditionally. That is what was decided by votes - to make type conversions fail on valu

Re: [PHP-DEV] 7.0 Release Management

2015-04-29 Thread Pierre Joye
On Thu, Apr 30, 2015 at 2:45 AM, Leigh wrote: > > On 29 April 2015 at 14:21, Anatol Belski wrote: >> >> after the recent discussion on IRC I would like to express the rediness to >> take on this job. As Kalle is willing to take this role as well, it'd >> probably make sense to hear what everyone

Re: [PHP-DEV] 7.0 Release Management

2015-04-29 Thread Pierre Joye
hi Julien. On Wed, Apr 29, 2015 at 10:50 PM, Julien Pauli wrote: > On Wed, Apr 29, 2015 at 3:57 PM, Anatol Belski > wrote: >> >> On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote: >> > On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski >> > wrote: >> > >> > >> >> Hi, >> >> >> >> >> >> On Sun, April

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Stas, On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev wrote: > > The objective to have type "hint" is to remove such checks by users, > > isn't it? > > No, not really. The objective is to ensure type of the parameter. If you > checks are not limited to types, then typing is not going to h

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Stanislav Malyshev
Hi! > The issue targeted here is "two extensions overriding php_error_cb can't > live side by side" and that issue exists since PHP 4.0. Should a bug report > be opened? I'm not sure why can't they live side by side. Of course, if the override is made in incompatible manner, they can't, but the s

Re: [PHP-DEV] Re: [RFC] Spaceship operator RFC

2015-04-29 Thread Christoph Becker
Stanislav Malyshev wrote: > Yeah compare_function can actually return more than 1, 0 and -1, esp. > for arrays but maybe . I'm not sure if we should change this or not. It > should be pretty easy to fix, just not sure why it's this way now - see > zend_compare_arrays and down to zend_hash_compare.

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Stanislav Malyshev
Hi! > The objective to have type "hint" is to remove such checks by users, > isn't it? No, not really. The objective is to ensure type of the parameter. If you checks are not limited to types, then typing is not going to help, and I don't think inventing special built-in type for each narrow use

Re: [PHP-DEV] Re: [RFC] Spaceship operator RFC

2015-04-29 Thread Stanislav Malyshev
Hi! > Found something else today > > http://3v4l.org/mO48q > > echo [1, 2, 3] <=> []; // 1 but it gives 3 Yeah compare_function can actually return more than 1, 0 and -1, esp. for arrays but maybe . I'm not sure if we should change this or not. It should be pretty easy to fix, just not sure why

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Christoph, On Thu, Apr 30, 2015 at 7:10 AM, Christoph Becker wrote: > Yasuo Ohgaki wrote: > > > On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker > wrote: > > > >> A solution for this issue has been proposed by the "Big Integer Support" > >> RFC which has been withdrawn. It's too late for P

Re: [PHP-DEV] Remove old PHP6 forward compatibility

2015-04-29 Thread Stanislav Malyshev
Hi! > Back when PHP6 was actually a thing, we added the 'b' string literal > prefix and the (binary) cast to be forward compatible with PHP6, > however since the entire unicode strings part were dropped, these are > no longer needed. > > I think its safe to remove these 2, and take it as a lessio

Re: [PHP-DEV] Reserve even more type hints RFC

2015-04-29 Thread Ángel González
On 30/04/15 00:41, Christoph Becker wrote: Hi everybody! I've noticed that the "Reserve Even More Types in PHP 7" RFC[1] has been moved to "Process and Policy" with the comment "needs no impl". However, the RFC states: | This RFC does not fully reserve them as keywords; it only prohibits | thei

[PHP-DEV] Reserve even more type hints RFC

2015-04-29 Thread Christoph Becker
Hi everybody! I've noticed that the "Reserve Even More Types in PHP 7" RFC[1] has been moved to "Process and Policy" with the comment "needs no impl". However, the RFC states: | This RFC does not fully reserve them as keywords; it only prohibits | their usage as class, interface and trait names.

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Christoph Becker
Hi Yasuo, Yasuo Ohgaki wrote: > On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker wrote: > >> A solution for this issue has been proposed by the "Big Integer Support" >> RFC which has been withdrawn. It's too late for PHP 7.0 to re-open it, >> but it might be reasonable to to so for PHP 7.1. >

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Nathan Bruer
This has been a big issue that I have ran into many times in the past for large framework projects, instead of building it out with "strict" types like: int, float, string, exc... It makes more sense to allow a user to define a psudo-type themselves which PHP will pass the arguments into to be "cle

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Christoph, On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker wrote: > > On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas > wrote: > > > >> I agree with Stanislav here, if you want to accept any type of number, > its > >> easy enough to add your own checking to do that with the wonderful > >> is_

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Francois, On Thu, Apr 30, 2015 at 6:23 AM, Yasuo Ohgaki wrote: > Allowing any forms of int/float as string(and GMP) for weak mode int/float > type hint > would be alternative resolution for this issue. I think it's better than > "numeric" type > hint. > > It seems current weak/strict type hin

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Christoph Becker
Yasuo Ohgaki wrote: > On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas wrote: > >> I agree with Stanislav here, if you want to accept any type of number, its >> easy enough to add your own checking to do that with the wonderful >> is_numeric. And for simplicity, make an invalidArgument method that y

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Francois, On Wed, Apr 29, 2015 at 7:03 PM, François Laupretre wrote: > > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo > > Ohgaki > > > > External data can have any form of numbers. > > Current PHP can handle them as "string". However PHP7's type hint cannot > > handle

Re: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread Yasuo Ohgaki
Hi Stas and Ryan, On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas wrote: > > External data can have any form of numbers. >> > Current PHP can handle them as "string". However PHP7's type hint cannot >> > handle numeric data well because it only has "int" and "float" hints. >> >> This is exactly wha

Re: [PHP-DEV] 7.0 Release Management

2015-04-29 Thread Leigh
On 29 April 2015 at 14:21, Anatol Belski wrote: > > after the recent discussion on IRC I would like to express the rediness to > take on this job. As Kalle is willing to take this role as well, it'd > probably make sense to hear what everyone thinks about my proposition. > Possibly it could come t

Re: [PHP-DEV] [VOTE] Exceptions in the engine

2015-04-29 Thread Sebastian Bergmann
Am 21.03.2015 um 18:05 schrieb Sebastian Bergmann: > The vote for this missed the boat for the PHP 7 deadline. However, if > we really want to do this we should do it in PHP 7 or not at all (at > least not for a long time) due to BC breaks. > > Thoughts? ping -- PHP Internals - PHP Runtime Dev

Re: [PHP-DEV] Re: [RFC] Spaceship operator RFC

2015-04-29 Thread Pasindu De Silva
Found something else today http://3v4l.org/mO48q echo [1, 2, 3] <=> []; // 1 but it gives 3 On Mon, Apr 20, 2015 at 7:29 PM, Pasindu De Silva wrote: > Hi > Found this while trying to do the documentation, Thought the same that it > was a RFC mistake, > therefore didn't put any examples. Will d

Re: [PHP-DEV] 7.0 Release Management

2015-04-29 Thread Julien Pauli
On Wed, Apr 29, 2015 at 3:57 PM, Anatol Belski wrote: > On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote: > > On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski > > wrote: > > > > > >> Hi, > >> > >> > >> On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote: > >> > >>> bumping the thread as we should st

Re: [PHP-DEV] 7.0 Release Management

2015-04-29 Thread Pierre Joye
Sounds good too :) Three will have plenty to do very soon On Apr 29, 2015 8:35 PM, "Ferenc Kovacs" wrote: > > > On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski > wrote: > >> Hi, >> >> On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote: >> > bumping the thread as we should start the release steps (

Re: [PHP-DEV] 7.0 Release Management

2015-04-29 Thread Anatol Belski
On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote: > On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski > wrote: > > >> Hi, >> >> >> On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote: >> >>> bumping the thread as we should start the release steps (branching >>> out 7.0, >>> tagging the first alpha or m

Re: [PHP-DEV] 7.0 Release Management

2015-04-29 Thread Ferenc Kovacs
On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski wrote: > Hi, > > On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote: > > bumping the thread as we should start the release steps (branching out > > 7.0, > > tagging the first alpha or more likely beta) if we wanna keep up with > > https://wiki.php.net/

RE: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Pierre Joye
On Apr 29, 2015 8:11 PM, "Zeev Suraski" wrote: > > > -Original Message- > > From: Ferenc Kovacs [mailto:tyr...@gmail.com] > > Sent: Wednesday, April 29, 2015 2:54 PM > > To: franc...@php.net; Zeev Suraski > > Cc: Pierre Joye; Adam Harvey; Patrick ALLAERT; Olivier Garcia; PHP > > Internals;

Re: [PHP-DEV] 7.0 Release Management

2015-04-29 Thread Anatol Belski
Hi, On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote: > bumping the thread as we should start the release steps (branching out > 7.0, > tagging the first alpha or more likely beta) if we wanna keep up with > https://wiki.php.net/rfc/php7timeline > after the recent discussion on IRC I would like to

RE: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Zeev Suraski
> -Original Message- > From: Ferenc Kovacs [mailto:tyr...@gmail.com] > Sent: Wednesday, April 29, 2015 2:54 PM > To: franc...@php.net; Zeev Suraski > Cc: Pierre Joye; Adam Harvey; Patrick ALLAERT; Olivier Garcia; PHP > Internals; > Kalle Sommer Nielsen > Subject: Re: [PHP-DEV] [RFC][VOTE] I

RE: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread François Laupretre
> De : Ferenc Kovacs [mailto:tyr...@gmail.com] > > For PHP7 we had a previously voted on and accepted timeline > (https://wiki.php.net/rfc/php7timeline) which stated marc 15 as > the last time for RFCs targetting php7, and as far as I can tell, everybody > seemed to agree that any RFC targettin

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Patrick ALLAERT
Le mer. 29 avr. 2015 à 10:57, Kalle Sommer Nielsen a écrit : > I would love to see more work toward identifying issues in PHP7, and > hopefully we can get that once we release the first alpha. > The issue targeted here is "two extensions overriding php_error_cb can't live side by side" and that

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Ferenc Kovacs
On Wed, Apr 29, 2015 at 12:24 PM, François Laupretre wrote: > > De : Pierre Joye [mailto:pierre@gmail.com] > > > > I would suggest then to end the white card given with the php7 rfc > > +1 on this. How can we make it official ? How can we stop the changes > merged to the PHP 7 branch every da

RE: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread François Laupretre
> De : Pierre Joye [mailto:pierre@gmail.com] > > I would suggest then to end the white card given with the php7 rfc +1 on this. How can we make it official ? How can we stop the changes merged to the PHP 7 branch every day ? Start a 7.1 branch ? François -- PHP Internals - PHP Runtime D

RE: [PHP-DEV] Remove old PHP6 forward compatibility

2015-04-29 Thread François Laupretre
> De : kalle@gmail.com [mailto:kalle@gmail.com] De la part de Kalle > Sommer Nielsen > > Back when PHP6 was actually a thing, we added the 'b' string literal > prefix and the (binary) cast to be forward compatible with PHP6, > however since the entire unicode strings part were dropped, the

RE: [PHP-DEV] Adding "numeric" type hint

2015-04-29 Thread François Laupretre
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo > Ohgaki > > External data can have any form of numbers. > Current PHP can handle them as "string". However PHP7's type hint cannot > handle numeric data well because it only has "int" and "float" hints. > > http://3v4l.org/6

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Patrick ALLAERT
Le mer. 29 avr. 2015 à 03:19, Pierre Joye a écrit : > On Apr 29, 2015 5:38 AM, "Adam Harvey" wrote: > > > > On 28 April 2015 at 15:10, Patrick ALLAERT > wrote: > > > Le mar. 28 avr. 2015 à 20:42, Kalle Sommer Nielsen a > écrit : > > > > > >> I should probably have been faster at replying, but

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

2015-04-29 Thread Kalle Sommer Nielsen
Hi Patrick 2015-04-29 0:10 GMT+02:00 Patrick ALLAERT : > "No go"? Isn't that a bit rough? Well we need to be fair and hold our own policies/processes we agree to true, else there is no point in having them. > > That kind of change normally doesn't require an RFC at all. We did one for > document

[PHP-DEV] Remove old PHP6 forward compatibility

2015-04-29 Thread Kalle Sommer Nielsen
Howdy Back when PHP6 was actually a thing, we added the 'b' string literal prefix and the (binary) cast to be forward compatible with PHP6, however since the entire unicode strings part were dropped, these are no longer needed. I think its safe to remove these 2, and take it as a lession learned,