Re: [PHP-DEV] RFC - Immutable classes

Hi Fleshgrinder, Since Michal answered most of the questions, I'll just add some notes. Initially I added restrictions to abstract classes, but I did think about that over the last couple of days and couldn't find any concrete reason for that restriction, so I think I'm going to remove that. As fa

Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module

On 02/09/16 01:25, Yasuo Ohgaki wrote: > I don't understand why new validator would cause more problems than > solving. If users validate all inputs (e.g. request headers, cookies, > all of post/get tampering), apps became much more secure. This task > does not belong to business(app) logic. Even w

Re: [PHP-DEV] RFC - Immutable classes

thank you for the clarification, more questions inline :) On 09/02/2016 04:23 AM, Michał Brzuchalski wrote: > Firstly, thanks for your interest. > My answers are inline. > > 2016-09-01 23:48 GMT+02:00 Mathieu Rochette : > >> >> On 09/01/2016 09:12 PM, Fleshgrinder wrote: >>> On 9/1/2016 3:49 PM,

Re: [PHP-DEV] RFC - Immutable classes

>From point of immutability of object, there is no difference if property is defined or not, so you are correct, last line in your code will throw an error. 2016-09-02 11:06 GMT+02:00 Mathieu Rochette : > thank you for the clarification, more questions inline :) > > > On 09/02/2016 04:23 AM, Mich

Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module

Hi Lester, On Fri, Sep 2, 2016 at 5:42 PM, Lester Caine wrote: > On 02/09/16 01:25, Yasuo Ohgaki wrote: >> I don't understand why new validator would cause more problems than >> solving. If users validate all inputs (e.g. request headers, cookies, >> all of post/get tampering), apps became much m

Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module

On 02/09/2016 11:11, Yasuo Ohgaki wrote: Taking care of tampered data by business logic will reduce both readability and maintainability. And more importantly, make code less secure because programmers tend to focus on logic in model, not input data validations. This certainly makes sense. I gu

Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module

On 02/09/16 11:11, Yasuo Ohgaki wrote: > Why shouldn't we have more secure validation? No argument about that ... only that ALL validation requires rules. If you have rules for preventing 'injection attacks' they only need to be applied to data that could allow that injection to be carried forward

Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module

On 02/09/16 11:37, Rowan Collins wrote: > If somebody's *not* using a library to build the form (e.g. they're > laying out the HTML by hand), are they likely to set up the complex > validation settings needed by the filter_* functions? The main problem is the lack of well built libraries that also

[PHP-DEV] Non-conflicting PHP 5 and 7 builds

Most developers who hope to move a site to PHP 7 will still have to maintain PHP 5 sites for a long time, requiring the presence of both. However, building either one, even with the `--program-suffix` configuration option still overwrites some files, like phpize and all the headers in ${prefix}/inc

Re: [PHP-DEV] Non-conflicting PHP 5 and 7 builds

Hi Jordan. Great Idea. There are just a few questions I have: * Is it possible to extend that system also to minor and patch versions? * What effect has that on docker or vagrant systems? Especially on maintainability of up-to-date versions that will have to symlink the current version to a new

Re: [PHP-DEV] Non-conflicting PHP 5 and 7 builds

On Fri, Sep 2, 2016 at 9:28 AM, Jordan Gigov wrote: > Most developers who hope to move a site to PHP 7 will still have to > maintain PHP 5 sites for a long time, requiring the presence of both. > However, building either one, even with the `--program-suffix` > configuration option still overwrites

Re: [PHP-DEV] RFC - Immutable classes

Well at the moment expection is thrown in case when you try to clone immutable object. But you do seem to have valid point there regarding __clone method. I'm definitely going to give it a thought. Best, Silvio. 2016-09-02 15:52 GMT+02:00 André Rømcke : > > > > On Sep 2, 2016, at 09:10 , Silvio

Re: [PHP-DEV] Non-conflicting PHP 5 and 7 builds

I'll try to answer as best I can. > Is it possible to extend that system also to minor and patch versions? Extending it to allow minor versions would require some changes in "scripts/phpize.m4" and "scripts/phpize.in" to make that information available to extensions, without having to parse the ve

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-09-02

Results for project PHP master, build date 2016-09-02 06:24:51+03:00 commit: edc4de5 previous commit:a3c1626 revision date: 2016-09-01 23:54:33+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] RFC - Immutable classes

On 09/02/2016 09:06 AM, Silvio Marijić wrote: Well at the moment expection is thrown in case when you try to clone immutable object. But you do seem to have valid point there regarding __clone method. I'm definitely going to give it a thought. Best, Silvio. 2016-09-02 15:52 GMT+02:00 André Rømc

Re: [PHP-DEV] RFC - Immutable classes

Hi Larry, I'm aware of that but we do have make some strong constraints there otherwise we are undermining the strong guarantee of immutability. I would agree to allow object modification only and only *inside* __construct() and __clone methods. I'm trying to come up with idea how would that look l

Re: [PHP-DEV] RFC - Immutable classes

Basically I'm concerned about __clone() since you can not pass parameters 2016-09-02 16:44 GMT+02:00 Silvio Marijić : > Hi Larry, > I'm aware of that but we do have make some strong constraints there > otherwise we are undermining the strong guarantee of immutability. I would > agree to allow obj

Re: [PHP-DEV] RFC - Immutable classes

02.09.2016 16:29 "Larry Garfield" napisał(a): > > On 09/02/2016 09:06 AM, Silvio Marijić wrote: >> >> Well at the moment expection is thrown in case when you try to clone >> immutable object. But you do seem to have valid point there regarding >> __clone method. I'm definitely going to give it a t

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

Dmitry, Poking around, I'm must not be understanding how TICK opcodes would negatively impact the lookahead. It may be my newness, but the way I'm reading the compilation of ZEND_AST_DIM, would not be suspect to random TICK opcodes from impacting the lookahead. I see that for a single ZEND_AST_D

Re: [PHP-DEV] RFC - Immutable classes

Michal I'm talking about __clone() callback after clone operation. But I agree with you about syntax part. 2016-09-02 16:46 GMT+02:00 Michał Brzuchalski : > 02.09.2016 16:29 "Larry Garfield" napisał(a): > > > > On 09/02/2016 09:06 AM, Silvio Marijić wrote: > >> > >> Well at the moment expection

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

On 22 March 2016 at 17:00, Scott Arciszewski wrote: > Hi all, > > https://wiki.php.net/rfc/mcrypt-viking-funeral > > The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a 79.3% > favorable response, which exceeds the 2/3 majority by a significant margin. > > Thanks to everyone who

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

I would still be OK adding this in RC2, TBH. I didn't realize it was missed, and it's something we _need_ to do. - Davey On Fri, Sep 2, 2016 at 8:08 AM, Leigh wrote: > On 22 March 2016 at 17:00, Scott Arciszewski wrote: > > Hi all, > > > > https://wiki.php.net/rfc/mcrypt-viking-funeral > > > >

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

I thought someone beat me to it? Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises On Fri, Sep 2, 2016 at 11:18 AM, Davey Shafik wrote: > I would still be OK adding this in RC2, TBH. I didn't realize it was > missed, and it's something we _need_

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

That would be why I thought it hadn't been missed! Thanks Scott (and Christoph :) - Davey On Fri, Sep 2, 2016 at 8:19 AM, Scott Arciszewski wrote: > https://github.com/php/php-src/pull/1996 > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

https://github.com/php/php-src/pull/1996 Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises On Fri, Sep 2, 2016 at 11:18 AM, Scott Arciszewski wrote: > I thought someone beat me to it? > > Scott Arciszewski > Chief Development Officer > Paragon In

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On 02.09.2016 at 16:57, David Walker wrote: > Poking around, I'm must not be understanding how TICK opcodes would > negatively impact the lookahead. It may be my newness, but the way I'm > reading the compilation of ZEND_AST_DIM, would not be suspect to random > TICK opcodes from impacting the lo

Re: [PHP-DEV] Non-conflicting PHP 5 and 7 builds

On Fri, Sep 2, 2016 at 6:28 AM, Jordan Gigov wrote: > Most developers who hope to move a site to PHP 7 will still have to > maintain PHP 5 sites for a long time, requiring the presence of both. > However, building either one, even with the `--program-suffix` > configuration option still overwrites

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On Fri, Sep 2, 2016 at 9:28 AM Christoph M. Becker wrote: > On 02.09.2016 at 16:57, David Walker wrote: > > > Poking around, I'm must not be understanding how TICK opcodes would > > negatively impact the lookahead. It may be my newness, but the way I'm > > reading the compilation of ZEND_AST_DIM

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

On 2 September 2016 at 16:18, Davey Shafik wrote: > I would still be OK adding this in RC2, TBH. I didn't realize it was missed, > and it's something we _need_ to do. > > - Davey Actually, my apologies. I appear to have been living in the future and was expecting mcrypt to have been removed this

[PHP-DEV] PHP 5.6.26 RC1 is available for testing

Hello everyone, PHP 5.6.26 RC1 was just released and can be downloaded from: http://downloads.php.net/~tyrael/ The Windows binaries are available at http://windows.php.net/qa/ This release contains a number of bugfixes. For the list of bugfixes that you can target in your testing, please refer

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

On 02.09.2016 at 17:24, Davey Shafik wrote: > That would be why I thought it hadn't been missed! > > Thanks Scott (and Christoph :) And Thomas: Cheers! > - Davey > > On Fri, Sep 2, 2016 at 8:19 AM, Scott A

[PHP-DEV] Re: [RFC][VOTE]: Implement socket_getaddrinfo family

On 01.09.2016 at 02:12, David Walker wrote: > On Wed, Aug 24, 2016 at 9:26 AM David Walker wrote: > >> I'd like to open voting on my RFC[1] to implement getaddrinfo(). The RFC >> implements 4 new socket extension functions to aid in the calling, >> examining, and connect/binding of the addrinfo

Re: [PHP-DEV] SQLite 3.14

On 31.08.2016 at 05:46, Davey Shafik wrote: > Sorry, I dropped the ball on this one: > > ../sapi/cli/php -d "output_handler=" -d "open_basedir=." -d > "disable_functions=" -d "output_buffering=Off" -d "error_reporting=32767" > -d "display_errors=1" -d "display_startup_errors=1" -d "log_errors=0

Re: [PHP-DEV] SQLite 3.14

Good find with that other test! I don't see any reason not to fix it for 5.6+ - Davey On Fri, Sep 2, 2016 at 12:08 PM, Christoph M. Becker wrote: > On 31.08.2016 at 05:46, Davey Shafik wrote: > > > Sorry, I dropped the ball on this one: > > > > ../sapi/cli/php -d "output_handler=" -d "open_b

[PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Hi internals, I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+) in their place. https://wiki.php.net/rfc/deprecate-pear-include-composer I highly recommend reading the twitter poll and accompanyin

[PHP-DEV] Re: [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Also, just wanted to say: As a former fairly major contributor to PEAR (see: http://pear.php.net/user/davey) I understand that PEAR has a special place in the heart of many old-school PHP developers — but I believe that the community has spoken, through lack of action on PEARs part, and the rapid

Re: [PHP-DEV] SQLite 3.14

On 02.09.2016 at 21:21, Davey Shafik wrote: > Good find with that other test! > > I don't see any reason not to fix it for 5.6+ Fine, I'll see to it. Cheers! > - Davey > > On Fri, Sep 2, 2016 at 12:08 PM, Christoph M. Becker > wrote: > >> On 31.08.2016 at 05:46, Davey Shafik wrote: >> >>> S

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Fri, Sep 2, 2016 at 2:33 PM Davey Shafik wrote: > Hi internals, > > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove > in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+) > in their place. > > https://wiki.php.net/rfc/deprecate-pear-include-comp

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Fri, Sep 2, 2016 at 12:57 PM, James Gilliland wrote: > On Fri, Sep 2, 2016 at 2:33 PM Davey Shafik wrote: > > > Hi internals, > > > > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and > remove > > in 8.0), as well as add composer/pickle (optional in 7.2, default in > 7.3+) >

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Fri, Sep 2, 2016 at 1:33 PM Davey Shafik wrote: > Hi internals, > > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove > in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+) > in their place. > > https://wiki.php.net/rfc/deprecate-pear-include-comp

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Fri, Sep 2, 2016 at 1:32 PM, Davey Shafik wrote: > Hi internals, > > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove > in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+) > in their place. > > https://wiki.php.net/rfc/deprecate-pear-include-com

[PHP-DEV] wiki.php.net access

Hi there! I just singed up at https://wiki.php.net . It instructed me to write a quick E-Mail to this address to prove I’m human. My username is: ilijatovilo Basically, I’ve been working with PHP professionally for quite a few years. The thing I’m mostly interested in is

Re: [PHP-DEV] wiki.php.net access

2016-09-03 1:56 GMT+02:00 Ilija Tovilo : > Basically, I’ve been working with PHP professionally for quite a few years. > The thing I’m mostly interested in is giving feedback to RFCs. I’ve worked > with a variety of different programming languages and think that I can bring > some valid argument