Re: [PHP-DEV] [RFC] Fiber support (again)

> On Feb 7, 2018, at 7:05 PM, Haitao Lv wrote: > > Hi internals, > > I propose to introduce the Fiber feature AGAIN. > > The main purpose of the RFC is to introducing a lightweight stackful > coroutine support for PHP and make it possible to write non-blocking code in > the

[PHP-DEV] [RFC] Fiber support (again)

Hi internals, I propose to introduce the Fiber feature AGAIN. The main purpose of the RFC is to introducing a lightweight stackful coroutine support for PHP and make it possible to write non-blocking code in the blocking style. In this RFC, no new keyword is needed. So it will not break the

Re: [PHP-DEV] Replaced the bundled libgd with upstream (aka. system)libgd

On 07.02.2018 at 21:04, Stanislav Malyshev wrote: >> bundled libgd)[5]. Another important difference is that our bundled >> libgd uses ZendMM, but upstream libgd does not[6]. > > This one we need to find a solution for. GD is often exposed to the > unfiltered user input, has a potential to

Re: [PHP-DEV] Replaced the bundled libgd with upstream (aka. system) libgd

Hi! > During the discussion of PR 3080[1] the idea to replace our bundled > libgd with an (unmodified) upstream libgd[2] has come up again. It > seems this issue deserves its own discussion, and probably an RFC. I think this is a good idea. In general, as open source ecosystem matures (and more

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

On 06.02.2018 at 20:31, Stanislav Malyshev wrote: >> Do we? AFAIK, it is not possible to import *all* functions (or even all >> symbols, for that matter) of a namespace, without explicitly mentioning >> them. > > We are talking about global namespace aka standard PHP functions, so it > works

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

On 7 February 2018 at 16:56, Andrey Andreev wrote: > Hi, > > What's not obvious (to me at least) here is why is the current > behavior preventing a ("sensible", as the RFC desribes it) > implementation of function autoloading? That seems to be a major > motivation factor for

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi, What's not obvious (to me at least) here is why is the current behavior preventing a ("sensible", as the RFC desribes it) implementation of function autoloading? That seems to be a major motivation factor for the proposal, yet doesn't seem to be explained anywhere. Cheers, Andrey. -- PHP

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

On 7 February 2018 at 15:20, Christoph M. Becker wrote: > On 07.02.2018 at 15:02, Rowan Collins wrote: > > > - PHP 7.3: Add syntax to explicitly reference functions and constants in > > the current namespace, such as .\foo or this\foo > > It is already possible to use the

[PHP-DEV] Replaced the bundled libgd with upstream (aka. system) libgd

Hi everybody! During the discussion of PR 3080[1] the idea to replace our bundled libgd with an (unmodified) upstream libgd[2] has come up again. It seems this issue deserves its own discussion, and probably an RFC. Our bundled libgd (particularly as found in master) is mostly compatible with

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

On Wed, Feb 7, 2018 at 7:02 AM, Rowan Collins wrote: > On 3 February 2018 08:27:18 GMT+00:00, Wes wrote: >>Hello PHPeople. I just published the RFC "Deprecation of fallback to >>root >>scope". >>

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

On 07.02.2018 at 15:02, Rowan Collins wrote: > - PHP 7.3: Add syntax to explicitly reference functions and constants in > the current namespace, such as .\foo or this\foo It is already possible to use the `namespace` keyword for this, see . > - Slightly uglier syntax.

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

On 3 February 2018 08:27:18 GMT+00:00, Wes wrote: >Hello PHPeople. I just published the RFC "Deprecation of fallback to >root >scope". > >https://wiki.php.net/rfc/fallback-to-root-scope-deprecation Given the discussion so far, how about taking the "opposite" approach: