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

Hi Lester, On Fri, Sep 2, 2016 at 7:58 PM, Lester Caine wrote: > A filter of "is this string corrupted with an injection attempt" seems > rather more difficult to define than "email"? And applying the first in > general on every string when there are as set of simple filters

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

Hi Rowan, On Fri, Sep 2, 2016 at 7:37 PM, Rowan Collins wrote: > 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

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 11:09 PM, Andrea Faulds wrote: > Hi Nikita, > > Nikita Popov wrote: > >> As I see it, the issue here is really not how to figure out whether a file >> uses strict_types, the issue is how you mix strict_types=1 and >> strict_types=0 code in a single file. >> >

[PHP-DEV] Re: The death of `#ifndef FAST_ZPP`?

Hi again, I finally wrote a patch to get rid of it: https://github.com/php/php-src/pull/2118 Perhaps this will go somewhere. :) -- Andrea Faulds https://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Missing reflection info about strict types?

Hi Nikita, Nikita Popov wrote: As I see it, the issue here is really not how to figure out whether a file uses strict_types, the issue is how you mix strict_types=1 and strict_types=0 code in a single file. This is also my assessment. Back when this feature was introduced, we decided not to

Re: [PHP-DEV] Missing reflection info about strict types?

On 9/5/2016 10:38 PM, Nikita Popov wrote: > Stripping strict_types declaration will change the behavior of the code > declared *within those files* (not the code calling that code). The > behavior should not change in the merge process. > > As I see it, the issue here is really not how to figure

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 10:30 PM, Davey Shafik wrote: > On Mon, Sep 5, 2016 at 1:13 PM, Nicolas Grekas > wrote: > > > > Why do you concatenate these files in the first place? > > > > > > > > > > It's not specifically me but Symfony's

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 1:13 PM, Nicolas Grekas wrote: > > Why do you concatenate these files in the first place? > > > > > > It's not specifically me but Symfony's ClassCollectionLoader::load() > method, which generates a single file with common classes inlined for >

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

On 05/09/16 19:51, Davey Shafik wrote: > https://github.com/dshafik/php7-mysql-shim — I already solved that problem, > at least in the short term. Another one for PHPSurgery MUST get that updated ... when time permits. -- Lester Caine - G8HFL - Contact -

Re: [PHP-DEV] Missing reflection info about strict types?

> Why do you concatenate these files in the first place? > > It's not specifically me but Symfony's ClassCollectionLoader::load() method, which generates a single file with common classes inlined for faster bootstrapping (the perf gain is objectively measurable). You give this method a list of

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

On Mon, Sep 5, 2016 at 8:31 AM, Michael Morris wrote: > Please be cautious - composer isn't a complete replacement for PEAR > because it doesn't behave the same way. For the most part this is a good > thing, but please consider the following. > > On not one but two occasions

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

On Mon, Sep 5, 2016 at 8:57 AM, Lester Caine wrote: > On 05/09/16 16:31, Michael Morris wrote: > > Also, as Tony Marston pointed out, there are CPanel systems that allow > the > > pear libraries to be managed from a web gui. Given time I'm sure the > folks > > at cpanel will

Re: [PHP-DEV] Re: [PREVOTE] PHP Engine Constants

On Mon, Sep 5, 2016 at 11:19 AM, Andrea Faulds wrote: > Hi Davey, > > Davey Shafik wrote: > >> A while back I brought a small RFC to internals, that proposed a set of >> constants that were specifically for alternative implementations to >> identify themselves as such if they want

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 7:38 PM, Andrea Faulds wrote: > Hi, > > Nicolas Grekas wrote: >> >> Thanks for trying Julien >> >> I guess what you miss for what you want to do, is to detect if strict >>> >>> types are activated into the current scope, at runtime. >>> >> >> From the inside,

[PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi Yasuo, Yasuo Ohgaki wrote: utf8_decode() and utf8_encode() are not needed and causing problems than solving. https://wiki.php.net/rfc/remove_utf_8_decode_encode Proposal - Document deprecation them now - Remove them from 7.2 I think only few users are using and they shouldn't have

Re: [PHP-DEV] Missing reflection info about strict types?

2016-09-05 17:25 GMT+02:00 Nicolas Grekas : > > > > being strict type it should not matter, at all > > > > It doesn't, except when trying to concatenate several source files into a > single bigger one. > Then we're stuck because declare(strict_type=0/1) is specifically

[PHP-DEV] Re: [PREVOTE] PHP Engine Constants

Hi Davey, Davey Shafik wrote: A while back I brought a small RFC to internals, that proposed a set of constants that were specifically for alternative implementations to identify themselves as such if they want to conform to the spec. https://wiki.php.net/rfc/php_engine_constant There were

Re: [PHP-DEV] Single Point of Entry Apps.

Hi Michael, Have you looked into PHP application servers, where the PHP code itself acts as the web (or FastCGI) server, and so can keep the whole framework etc. initialised in memory between requests? This is how other (non-PHP) web stacks avoid “installing the application on every single

Re: [PHP-DEV] Missing reflection info about strict types?

Hi, Nicolas Grekas wrote: Thanks for trying Julien I guess what you miss for what you want to do, is to detect if strict types are activated into the current scope, at runtime. From the inside, the author of the code knows if they added the declare or not. I'd need to know from the

Re: [PHP-DEV] How to properly fix issues in ext/zip?

On 05.09.2016 at 18:40, Remi Collet wrote: > Le 05/09/2016 à 18:23, Christoph M. Becker a écrit : > >> I've stumbled upon and could fix it, but >> I'm not sure whether the fix should be applied to php-src/ext/zip or >> rather against PECL/zip (i.e.

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

On 05/09/2016 11:13, Derick Rethans wrote: And it should work also work out of the box, without any other tricks or steps to make it working. That means, not having to run "composer install" in order to get a working "pickle" tool. A phar might be an idea. As I understand, PEAR already needs

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

On 05/09/2016 16:31, Michael Morris wrote: Also, as Tony Marston pointed out, there are CPanel systems that allow the pear libraries to be managed from a web gui. On 05/09/2016 16:57, Lester Caine wrote: So this is not about 'Deprecate' the code, but just the loader bit? Have a look at my

Re: [PHP-DEV] optionally return class name from gettype

On 9/5/2016 9:02 AM, Timothy Younger wrote: > thank you all for your feedback. it seems this thread is split between an > optional param and a new function, so i created a new function called > var_type for comparison. > > commit: >

Re: [PHP-DEV] How to properly fix issues in ext/zip?

Le 05/09/2016 à 18:23, Christoph M. Becker a écrit : > Hi! > > I've stumbled upon and could fix it, but > I'm not sure whether the fix should be applied to php-src/ext/zip or > rather against PECL/zip (i.e. ). > > So, which repo

Re: [PHP-DEV] RFC - Immutable classes

On 9/5/2016 4:21 AM, Michał Brzuchalski wrote: > You may begin with modifications on RFC eg. in a gist so we can all > discuss about it before putting on RFC, is that okay to you? Absolutely, that's how I thought about approaching it too because otherwise we might create a mess in the Wiki. On

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

On 05/09/2016 11:12, Michał Brzuchalski wrote: I think the idea involved from other languages package managers like nodejs I think you have your history in a twist there: node.js was first released in 2009, by which time PEAR was already ten years old, and heading towards decline. The more

[PHP-DEV] How to properly fix issues in ext/zip?

Hi! I've stumbled upon and could fix it, but I'm not sure whether the fix should be applied to php-src/ext/zip or rather against PECL/zip (i.e. ). So, which repo is the "master" – ext/zip or PECL/zip? -- Christoph M. Becker

Re: [PHP-DEV] Single Point of Entry Apps.

On 05.09.2016 at 18:03, Michael Morris wrote: > Something I was reminded of during the discussion of replacing pear with > composer that I thought was worthy of it's own thread. Most PHP apps I've > seen that use composer are > single point of entry apps - that is there's one front controller,

[PHP-DEV] Single Point of Entry Apps.

Something I was reminded of during the discussion of replacing pear with composer that I thought was worthy of it's own thread. Most PHP apps I've seen that use composer are single point of entry apps - that is there's one front controller, usually index.php, and .htaccess rules are put in place

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

On 05/09/16 16:31, Michael Morris wrote: > Also, as Tony Marston pointed out, there are CPanel systems that allow the > pear libraries to be managed from a web gui. Given time I'm sure the folks > at cpanel will build new interfaces for new systems if it's possible. > Composer however doesn't

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

2016. szept. 5. 17:32 ezt írta ("Michael Morris" ): > > Please be cautious - composer isn't a complete replacement for PEAR because > it doesn't behave the same way. For the most part this is a good thing, but > please consider the following. > > On not one but two occasions I

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

Please be cautious - composer isn't a complete replacement for PEAR because it doesn't behave the same way. For the most part this is a good thing, but please consider the following. On not one but two occasions I was tasked after being hired with upgrading PHP versions from 4.x to 5.3. In both

Re: [PHP-DEV] Missing reflection info about strict types?

> > being strict type it should not matter, at all > It doesn't, except when trying to concatenate several source files into a single bigger one. Then we're stuck because declare(strict_type=0/1) is specifically *not* allowed in the middle of a file, and *not* allowed to use the block syntax

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 5:49 AM, Davey Shafik wrote: > > > On Sep 5, 2016, at 02:38, Nicolas Grekas > wrote: > > > > Hello, > > > > It looks like we miss a way to check by reflection if a function/method > has > > strict types enabled or not. > > >

Re: [PHP-DEV] Missing reflection info about strict types?

Hi, On Sep 5, 2016 8:53 PM, "Julien Pauli" wrote: > > On Mon, Sep 5, 2016 at 3:19 PM, Julien Pauli wrote: > > On Mon, Sep 5, 2016 at 2:44 PM, Nicolas Grekas wrote: > >> Thanks for trying Julien > >> > >>> I guess what you miss for what

Re: [PHP-DEV] Missing reflection info about strict types?

2016-09-05 15:52 GMT+02:00 Julien Pauli : > On Mon, Sep 5, 2016 at 3:19 PM, Julien Pauli wrote: > > On Mon, Sep 5, 2016 at 2:44 PM, Nicolas Grekas > wrote: > >> Thanks for trying Julien > >> > >>> I guess what you miss for what you want

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 3:19 PM, Julien Pauli wrote: > On Mon, Sep 5, 2016 at 2:44 PM, Nicolas Grekas > wrote: >> Thanks for trying Julien >> >>> I guess what you miss for what you want to do, is to detect if strict >>> types are activated into the

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

Hi Tyrael On Sep 5, 2016 7:10 AM, "Ferenc Kovacs" wrote: > > You are probably talking about https://bugs.php.net/bug.php?id=71224. > > My understanding is that when fetching the packages from pecl.php.net > pickle would still have the same problem ( >

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 2:44 PM, Nicolas Grekas wrote: > Thanks for trying Julien > >> I guess what you miss for what you want to do, is to detect if strict >> types are activated into the current scope, at runtime. > > > From the inside, the author of the code knows if

Re: [PHP-DEV] Missing reflection info about strict types?

Thanks for trying Julien I guess what you miss for what you want to do, is to detect if strict > types are activated into the current scope, at runtime. > >From the inside, the author of the code knows if they added the declare or not. I'd need to know from the outside, before concatenating it,

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 11:38 AM, Nicolas Grekas wrote: > Hello, > > It looks like we miss a way to check by reflection if a function/method has > strict types enabled or not. > > We'd need to do this in Symfony to generate a file with concatenated > classes, but split

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-09-05

Results for project PHP master, build date 2016-09-05 06:24:49+03:00 commit: 880c13c previous commit:edc4de5 revision date: 2016-09-04 16:53:45+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] Deprecate PEAR/PECL & Replace with composer/pickle

On Fri, 2 Sep 2016, Davey Shafik wrote: > 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

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

2016-09-05 11:51 GMT+02:00 Dan Ackroyd : > On 2 September 2016 at 20:32, Davey Shafik wrote: > > 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 >

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

On 2 September 2016 at 20:32, Davey Shafik wrote: > 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. Even if Pear and Pecl overlap and share code, it

Re: [PHP-DEV] Missing reflection info about strict types?

> On Sep 5, 2016, at 02:38, Nicolas Grekas wrote: > > Hello, > > It looks like we miss a way to check by reflection if a function/method has > strict types enabled or not. > > We'd need to do this in Symfony to generate a file with concatenated > classes, but split

Re: [PHP-DEV] Missing reflection info about strict types?

2016-09-05 11:38 GMT+02:00 Nicolas Grekas : > Hello, > > It looks like we miss a way to check by reflection if a function/method has > strict types enabled or not. > This isn't bound to functions / methods and can't be reflected. > We'd need to do this in Symfony to

[PHP-DEV] Missing reflection info about strict types?

Hello, It looks like we miss a way to check by reflection if a function/method has strict types enabled or not. We'd need to do this in Symfony to generate a file with concatenated classes, but split "declare_strict=1" classes out so that they don't break (because there is no way to create a

Re: [PHP-DEV] RFC - Immutable classes

I had a talk at Room11 and we discussed idea of `mutator` keyword. There were some concerns using `mutator` as a keyword - that's because immutable object is not being muted and also magically appeared `$clone` would be confusing. There's an idea of creating clone before function begins and

Re: [PHP-DEV] optionally return class name from gettype

i just thought of another option. what if gettype returned the classname as a part of the "object" string, e.g. "object (point)", "object (stdClass)", "object (Exception)", etc. this would be similar to gettype's return on a closed resource: "resource (closed)":

Re: [PHP-DEV] optionally return class name from gettype

thank you all for your feedback. it seems this thread is split between an optional param and a new function, so i created a new function called var_type for comparison. commit: https://github.com/abacaphiliac/php-src/commit/eca6f77bf2744c79671d1dfbb641b753503d4a1a build: