Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 4:15 AM, Rasmus Schultz wrote: > FWIW, I've read the manual page for the Hack page, and the RFC, a couple of > times now, and I simply don't understand it. > Perhaps the documentation needs clarifying then. > Are most PHP developers going to understand this feature, the me

Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 8:15 AM, Rowan Collins wrote: > Glad it makes sense. :) I realise "return $$" would have to have some > special handling, but it would feel more natural to me. I guess the only > concern is what happens when a pipeline has a return terminal and is used in > expression conte

Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 1:11 PM, Stanislav Malyshev wrote: > There is a lot of ways in which PHP needs improvement, but right now I > think inventing more syntax tricks in not one of them. Even in syntax > department, PHP has areas where we could use improvement (e.g. to name > named arguments as

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

On Mon, Aug 1, 2016 at 3:52 PM, wrote: > I recently emailed the group about submitting an RFC for str_begins() and > str_ends() functions. The RFC has now been officially submitted and is > viewable at: > > https://wiki.php.net/rfc/add_str_begin_and_end_functions > Feeling "meh" on it (neither fo

Re: [PHP-DEV] Tracing exit()

On Thu, Aug 4, 2016 at 11:10 AM, Bishop Bettini wrote: > I'm wondering if the shutdown functions could access telemetry: > > register_shutdown_function(function () { > > $context = shutdown_get_context(); > > /** array ( 'exit' => array ('file' => '/path/to/Foo.php', 'line' => > 242, 'mes

Re: [PHP-DEV] Function auto-loading

On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine wrote: >> That is, when I'm running the test-suite of my package, the Composer >> project is the root folder of that package - but when the package is >> being consumed by another project, it's installed in a sub-folder in >> that project's "vendor" fol

Re: [PHP-DEV] Method compare()

On Tue, Aug 9, 2016 at 10:33 AM, David Rodrigues wrote: > Currently PHP has a method called "version_compare()". Should be great > if we have the same function but to general usage. There are some > implementations on web for that, but I guess that it could be done > natively. > Anything written i

[PHP-DEV] [RFC] OpenSSL BigNum support

As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL. https://wiki.php.net/rfc/openssl.bignum -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

> Looks ok to me. Would probably not hurt also add tests for various error > conditions. > There's one TypeError test in there, but I can easily add more. (And probably will on my flight tomorrow.) > I realise this is only exposing functionality already available with > OpenSSL but is it worth add

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

On Mon, Oct 17, 2016 at 11:41 PM, Sebastian Bergmann wrote: > Am 18.10.2016 um 08:23 schrieb Sara Golemon: >> I'm mostly curious about thoughts on API decisions. > > * public static function createFromBinary(string $number): BigNum; > * public static function create

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

On Sun, Oct 23, 2016 at 5:06 PM, Stanislav Malyshev wrote: >> What are the specific reasons for choosing OpenSSL Bignums over GMP, >> outside of extension availability (which is totally a path I don't want us >> to go down -- see also recent attempts to duplicate ext/mbstring into >> ext/standard)

Re: [PHP-DEV] Wiki - Extentions

On Thu, Nov 3, 2016 at 4:50 PM, Daniel Klein wrote: > The page https://wiki.php.net/internals/extensions has some spelling > mistakes and things that could be clearer. > > The heading: "Registering *additionnal *extensions from the SAPI module" > should be spelt *additional*. > Someone else seems

[PHP-DEV] [RFC] HashContext as Object

I was trawling through Pull Requests and found #660 which I think is a nice idea and deserves some attention. It involves minor BC however, so I've updated the patch and presented it for your discussing pleasure. https://wiki.php.net/rfc/hash-context.as-resource -Sara -- PHP Internals - PHP Ru

[PHP-DEV] Fwd: [RFC] HashContext as Object

On Mon, Dec 26, 2016 at 7:35 PM, Sara Golemon wrote: > I was trawling through Pull Requests and found #660 which I think is a > nice idea and deserves some attention. It involves minor BC however, > so I've updated the patch and presented it for your discussing > pleasure.

Re: [PHP-DEV] Introduction to the PHP source code

On 29/12/16 16:17, ilija.tov...@me.com wrote: > Looking at the giant repository I feel a little overwhelmed. Is there a > place where I can get started and learn more about the architecture of the > interpreter before diving into the source code itself? I’m sorry if this > question has been asked b

[PHP-DEV] Re: [PHP-CVS] com php-src: Use new param API in standard: ext/standard/browscap.c ext/standard/cyr_convert.c ext/standard/datetime.c ext/standard/dl.c ext/standard/dns.c ext/standard/fsock.c

On Sun, Jan 1, 2017 at 4:51 AM, Christoph M. Becker wrote: > On 01.01.2017 at 13:36, Derick Rethans wrote: >> I thought the idea was to only for this for functions that would be called >> often as the win is so little? > > The performance improvement can be considerable[1], but the downside is >

Re: [PHP-DEV] [RFC] Deprecate and remove INTL_IDNA_VARIANT_2003

On Sat, Jan 7, 2017 at 6:06 AM, Christoph M. Becker wrote: > Following up on , I have > written the RFC > > > > and hereby placing it under discussion. > > I appreciate reviews and com

Re: [PHP-DEV] Re: Mailing Lists and URLs Causing Rejections

On Mon, Jan 9, 2017 at 11:56 PM, Ferenc Kovacs wrote: > On Tue, Jan 10, 2017 at 4:21 AM, Ferenc Kovacs wrote: >> yeah, unfortunatelly ecelerity is a bit of a black box, here is the >> relevant config: >> If only someone on systems@ knew anything about ecelerity... Wez, have you ever heard of thi

[PHP-DEV] Fwd: [RFC] HashContext as Object

On Thu, Dec 29, 2016 at 6:32 PM, Sara Golemon wrote: > On Mon, Dec 26, 2016 at 7:35 PM, Sara Golemon wrote: >> I was trawling through Pull Requests and found #660 which I think is a >> nice idea and deserves some attention. It involves minor BC however, >> so I've updat

[PHP-DEV] [RFC][Vote] HashContext using Objects

Voting has opened on: https://wiki.php.net/rfc/hash-context.as-resource Voting will remain open for two weeks and will close on 31 Jan, 2017 at 23:59:59 UTC -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][Accepted] HashContext as Object

Voting on https://wiki.php.net/rfc/hash-context.as-resource has closed. The RFC has passed 15 to 0. Implementation specific selection: Frozen (9-6) I'll merge the diff later tonight or tomorrow. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.

Re: [PHP-DEV] Namespaces in Core

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder wrote: > First: I like namespaces in Core but here me out! > > The PHP (case does not matter) would be the proper vendor name to put > Core stuff in, as far as I remember it is also reserved for PHP > functionality. There were also numerous discussions

Re: [PHP-DEV] Namespaces in Core

On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov wrote: > I'm strongly against use of the PHP namespace as a blanket namespace for > bundled PHP extensions. The PHP namespace should be used only for > functionality that is actually in some way related to PHP. For example, the > php-ast extension could

Re: [PHP-DEV] Namespaces in Core

On Tue, Feb 7, 2017 at 6:59 PM, Dan Ackroyd wrote: > On 7 February 2017 at 17:56, Scott Arciszewski wrote: >> I'm taking all the No votes spawned by this thread to mean "we >> don't want namespaced functions ever". > > That would be a bad assumption. > Confirmed. I'm not against EVER having names

Re: [PHP-DEV] Improve (disable|enable)_functions #65386

On Thu, Jan 19, 2017 at 6:18 AM, Ben RUBSON wrote: > As proposed by cmb (thank you !), I open a discussion regarding req #65386 : > https://bugs.php.net/bug.php?id=65386 > > It summarizes requests around disable_functions directive : > - modification of disable_functions to be a PHP_INI_SYSTEM dir

Re: [PHP-DEV] Improve (disable|enable)_functions #65386

On Fri, Feb 10, 2017 at 4:02 AM, Ben RUBSON wrote: >> On 09 Feb 2017, at 18:12, Sara Golemon wrote: >> Could you clarify? `disable_functions` *IS* a PHP_INI_SYSTEM directive: >> >> PHP_INI_ENTRY("disable_functions", "", PHP_INI_SYSTEM, NULL) > >

Re: [PHP-DEV] Improve (disable|enable)_functions #65386

On Fri, Feb 10, 2017 at 4:09 PM, Ben RUBSON wrote: > I was talking more specifically about the following : > "php_admin_value disable_functions mydisfunction" > phpinfo() shows mydisfunction as locally disabled, > but in reality can still be used. > Uh... that sounds like a bug. That should absol

[PHP-DEV] Fix for invalid declare(ticks=expr); values

A crash report came into security@ (which needn't have been private) about a segfault in response to trying to compile clearly broken code. https://github.com/php/php-src/pull/2395 is a fix for this, but before I merge it (and check how far back it goes -- my suspicion is 7.0), I'm hoping for some

[PHP-DEV] [Request for Comment] Loading dynamic libraries with cross dependencies.

The average PHP extension is dependent only on the PHP runtime it was built for and probably one or more 3rd party libraries. However, a special class of extensions (such as PDO drivers and much of the XML family) have dependencies on other PHP extensions which may (or may not) be preset at the ti

Re: [PHP-DEV] [Request for Comment] Loading dynamic libraries with cross dependencies.

On Fri, Mar 3, 2017 at 5:47 AM, Derick Rethans wrote: >> The average PHP extension is dependent only on the PHP runtime it was >> built for and probably one or more 3rd party libraries. However, a >> special class of extensions (such as PDO drivers and much of the XML >> family) have dependencies

Re: [PHP-DEV] [Request for Comment] Loading dynamic libraries with cross dependencies.

>> Would I be correct in assuming there's a desire to resolve this issue? >> Or are we considering "know your dependencies and configure for them" >> to be enough? >> > > Configuration should be dead simple, having this load order requirements > is not dead simple. It is actually very complicated b

Re: [PHP-DEV] [Request for Comment] Loading dynamic libraries with cross dependencies.

On Mon, Mar 6, 2017 at 3:50 AM, Joe Watkins wrote: > FWIW, I wouldn't mind improvements in this area (apcu and the apc bc layer > suffer from this). > apcu_bc is exactly what precipitated this discussion for me. :) > Anything from a better error message, all the way to removing the necessary > lo

Re: [PHP-DEV] generating code from AST

On Mon, Mar 6, 2017 at 3:37 PM, Adam Baratz wrote: > I'm exploring how to automate some basic kinds of refactor operations. One > approach I'm considering: > >- Generate an AST >- Rearrange it as needed >- Turn it back into userland code > > Is this something anyone's explored? > The e

Re: [PHP-DEV] generating code from AST

On Mon, Mar 6, 2017 at 3:40 PM, Sara Golemon wrote: > On Mon, Mar 6, 2017 at 3:37 PM, Adam Baratz wrote: >> I'm exploring how to automate some basic kinds of refactor operations. One >> approach I'm considering: >> >>- Generate an AST >>- Rearr

Re: [PHP-DEV] array_values should be a no-op for packed layout arrays

On Tue, Mar 14, 2017 at 11:21 AM, Julien Pauli wrote: >> I noticed this commit >> > 9e853282fac968d9cd454> >> recently in HHVM, which makes array_values() return the same array back if >> it's packed instead of building a copy. >> >> My

Re: [PHP-DEV] array_values should be a no-op for packed layout arrays

On Tue, Mar 14, 2017 at 6:25 PM, Jesse Schalken wrote: > I didn't realise packed arrays could still have gaps. If that's the case, > why can't [12=>'foo', 42=>'bar'] be packed (index 0-11 and 13-41 are > undefined)? > It can be, but in practice isn't likely to be since that's a lot of empty space

[PHP-DEV] Unexpected results from constant folding

This comes in thanks to my old friend Fred Emmott on the HHVM project: https://3v4l.org/vUHq3 class Foo { const A = 1 << 0; const B = self::A | self::C; const C = 1 << 1; } class Bar extends Foo { const A = 1 << 2; const C = 1 << 3; } var_dump(decbin(Bar::B)); // HHVM result

Re: [PHP-DEV] Unexpected results from constant folding

On Wed, Mar 15, 2017 at 5:36 AM, Nikita Popov wrote: > Yes, this should behave as C. See also https://bugs.php.net/bug.php?id=69676 > for an existing bug report on the topic. > Given that bug is assigned to you, I'll just leave it in your hands then? > I think in 7.1 it might be even fairly simpl

Re: [PHP-DEV] Unexpected results from constant folding

On Wed, Mar 15, 2017 at 4:14 PM, Nikita Popov wrote: > Fixed in 7.1 by > https://github.com/php/php-src/commit/2bba4a0d7f6d5e5712d60bc1cf2119622d837e55. > Thanks! > I personally don't consider a PHP 7.0 backport worthwhile, as this is a long > standing issue (from early PHP 5 days) and the fix wi

Re: [PHP-DEV] Let range() return a generator?

On Fri, Mar 17, 2017 at 1:40 AM, Niklas Keller wrote: > Yes, that's a BC break. Instead of changing it, there could be a new > function. But as it can be simply built in userland, I don't see much > reason to have it in core. > 100% agreed. This is a 3 line function and doing it in userland means

Re: [PHP-DEV] Let range() return a generator?

On Fri, Mar 17, 2017 at 10:46 AM, Sara Golemon wrote: > On Fri, Mar 17, 2017 at 1:40 AM, Niklas Keller wrote: >> Yes, that's a BC break. Instead of changing it, there could be a new >> function. But as it can be simply built in userland, I don't see much >> reas

Re: [PHP-DEV] Let range() return a generator?

On Fri, Mar 17, 2017 at 8:40 PM, David Rodrigues wrote: > There are some way to PHP be flagged before run some function, and > understand that you wants to return a Generator instead of array? > For instance: new Generator(range(1, 1000)) makes range() work like a > generator instead of return an

Re: [PHP-DEV] Let range() return a generator?

On Fri, Mar 17, 2017 at 9:10 PM, David Rodrigues wrote: > In this case, when you call range() inside a Generator() constructor, then > the range() (in C++) will acts differently, like a xrange(). > Doable: Yes. Fundamentally broken within PHP's engine design: Definitely. Calling scope should abso

[PHP-DEV] RFC karma?

The author of https://github.com/php/php-src/pull/1927 wants RFC karma to propose some dynamic variable enhancements. Could someone with karma karma help them out? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: TOKEN_AS_OBJECT for token_get_all()

On Thu, 23 Mar 2017 18:16:31 +0100, Nikita Popov > I'd like to add a new TOKEN_AS_OBJECT flag to token_get_all(), which > returns an array of PhpToken objects, rather than the mix of plain strings > and arrays we currently have. The PhpToken class is defined as: > > class PhpToken { > public $

Re: [PHP-DEV] PHP 7.2 Release Managers

On Tue, Mar 28, 2017 at 9:56 AM, Joe Watkins wrote: > With the first alpha of 7.2 due in early June, we think it's time to start > the process of finding and electing release managers for the next minor > release of PHP. > > We are looking for two souls to take on this role. Whomsoever is elected

Re: [PHP-DEV] Directory separators on Windows

My first thought is UNC paths. On windows a file server share is denoted by \\host\share . if you combine that with relative paths produced from PHP, you end up in the dubious situation of "\\host\share/path/to/file" <--- wat? Overall, it smells of magic. -Sara On Thu, Mar 30, 2017 at 8:25 AM,

Re: [PHP-DEV] SHA3 is very slow

On Fri, Mar 31, 2017 at 10:12 PM, Yasuo Ohgaki wrote: > I noticed that our SHA-3 is inefficient. > Entirely possible. Feel free to improve it. :D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] SHA3 is very slow

On a similarly superficial scan, I have no issues with this. The only tiny thing which gives me pause is https://github.com/php/php-src/pull/2453/files#diff-0bb62bbdac4073ae183a857299826533R24 as I don't recall 100% if that redefinition will leak out to other parts of the runtime (my instinct says

Re: [PHP-DEV] PHP 7.2 Release Managers

On Fri, Apr 7, 2017 at 3:20 AM, Remi Collet wrote: > Le 07/04/2017 à 08:31, Davey Shafik a écrit : >> Thanks Remi! >> >> As the Release Process RFC requires two RMs[1], are you and Sara willing to >> collaborate as a team for 7.2? If not, you will each have to find a second >> team-mate :) > > Fro

[PHP-DEV] [7.2] Timetable

My how time flies! Feature Freeze for PHP-7.2 is coming up in exactly THREE MONTHS on July 20th. Get your RFCs discussed, voted on, and implemented unless you want to wait for PHP-7.3 -Sara Ref: https://wiki.php.net/todo/php72#timetable -- PHP Internals - PHP Runtime Development Mailing List

[PHP-DEV] On malformed transport strings

My fix to https://bugs.php.net/bug.php?id=74216 tightened down the definition of what a valid transport string looks like. Previously, transport strings like "tcp://127.0.0.1:80:81:82/your/moms/face" would be accepted by PHP as perfectly valid URIs. Since this was never documented as a feature of

Re: [PHP-DEV] Source tar.gz's extract slowly on some platforms

On Sat, Apr 22, 2017 at 8:38 AM, Thomas Hruska wrote: > It looks like ~700 files are added each year to whatever new version is > released. The bulk of the new files seem to involve the test suite. > I certainly hope the vast bulk of that is tests. :D > I'm only pointing out something I've notic

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Sat, Apr 22, 2017 at 4:40 AM, Colin O'Dell wrote: > I'd like to propose an enhancement to curl_setopt() > which is used to > configure a given curl session. The second argument of this function > defines which option to set and the third argu

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Mon, Apr 24, 2017 at 1:24 PM, Fleshgrinder wrote: > On 4/24/2017 10:20 PM, Stanislav Malyshev wrote: >> Hi! >> >>> Because each option expects the value to be a specific type, it makes sense >>> to enforce these types in strict type checking mode. I'd therefore like to >>> propose that we intr

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Mon, Apr 24, 2017 at 4:09 PM, Stanislav Malyshev wrote: > it's clearly > business logic. Which I have no problem with, but it shouldn't be part > of type system then. > We're certainly arguing semantics at this point. Let's agree that type enforcement is a good thing (which you seemed to say i

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Mon, Apr 24, 2017 at 9:00 PM, Michał Brzuchalski wrote: > I agree with Stanislav. IMHO argument types are valueable when are > reflective by reflection and curl_setopt has no valuable info by reflection > and will never be. Curl implementation also uses resources cURL handle is > used. > Litera

Re: [PHP-DEV] On malformed transport strings

On Tue, Apr 25, 2017 at 5:15 AM, Anatol Belski wrote: > I've applied the patch you've suggested in bug #74429, so it's going to be > included in RCs. Given the initial security issue is not impacted, BC can be > kept. > I thought about the security implications of that quick fix and while it doe

Re: [PHP-DEV] On malformed transport strings

On Wed, Apr 26, 2017 at 6:20 AM, Anatol Belski wrote: > Thanks for this additional check. My action was actually based on the comment > with the patch link, looks like the situation has now changed a bit. We're > still quite limited in choice in this case. For one, there's a low security > impa

Re: [PHP-DEV] On malformed transport strings

On Wed, Apr 26, 2017 at 1:19 PM, Anatol Belski wrote: > What I'd basically avoid is making changes in stress, > as there might be other beyond places and we shouldn't > risk to introduce more breach than there already is. > Instead, that requires a cold head and a lot of QA 😉 > Which is precisely

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Fri, Apr 28, 2017 at 9:34 AM, Markus Fischer wrote: > To me the intention of strict types is clearly on the functions publicly > visible contract, i.e. it's reflectable parameters and not some business > logic hidden inside a function. > So you feel that declare(strict_types=1); should never ap

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Fri, Apr 28, 2017 at 2:29 PM, Rowan Collins wrote: > On 28 April 2017 18:54:09 BST, Sara Golemon wrote: >>On Fri, Apr 28, 2017 at 9:34 AM, Markus Fischer >>wrote: >>> To me the intention of strict types is clearly on the functions >>publicly >>>

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Fri, Apr 28, 2017 at 6:05 PM, Rowan Collins wrote: >>I reject the idea of making a worse API for the sake of an artificial >>purity standard which has long since been violated elsewhere. > > Personally, I think if we were designing from scratch, having a > setHeaders method which took an array

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Sat, Apr 29, 2017 at 10:01 AM, Rowan Collins wrote: > That mix sounds very reasonable. Does it still make you go "eww" to suggest > that those settings that don't deserve their own method, and take a boolean > argument rather than a string or int, could have a different method, such as > setFla

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Sat, Apr 29, 2017 at 11:11 AM, Fleshgrinder wrote: > Let me be Bob, and my assumption would be completely different. I expect > that internals behave the same as userland implementations. I know that > this is not the case in every circumstance, but those where this > assumption does not hold t

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Sat, Apr 29, 2017 at 2:46 PM, Rowan Collins wrote: > In this case, we should acknowledge that userland cannot > (delta dirty backtrace hack) change behaviour based on > strict types inside the body of the function, and in most > cases neither sold internal functions. We can then decide > if thi

[PHP-DEV] ZEND_ARG_TYPE_INFO usage in core?

Spinning off a sub-thread: Does anyone know any particular reason why ZEND_ARG_TYPE_INFO is not (barring two windows specific functions in standard) used anywhere in core? Is it? 1. Nobody has done the grunt work since 7.0? 2. It breaks something? (should only impact reflection AIUI) 3. ??? I'd

Re: [PHP-DEV] ZEND_ARG_TYPE_INFO usage in core?

On Sat, Apr 29, 2017 at 3:54 PM, Nikita Popov wrote: > 1. In weak mode, arginfo type violations throw, while zpp violations warn > and return NULL. As such, adding arginfo types to existing functions is a BC > break. > 2. For methods in particular, prior to PHP 7.2, adding arginfo types was > also

Re: [PHP-DEV] the experimental jit-branch is impressive

On Tue, May 2, 2017 at 2:51 PM, li...@rhsoft.net wrote: > OK, than it are "only" 5% on a highly optimized codebase > Awww... that makes me kinda sad to hear. But perhaps with more work that needle can be moved upwards. One question which I didn't see answered (in my admittedly quick scan): What

Re: [PHP-DEV] the experimental jit-branch is impressive

On Tue, May 2, 2017 at 10:19 PM, li...@rhsoft.net wrote: > 100% internal codebase without 3rd party libraries developed over the last > 15 years and in the meantime 100% strict-types/typehints/return-types only > missing some commented nullable/void return types because i need to wait > with 7.1.x

Re: [PHP-DEV] [VOTE] First-class callable syntax

On Fri, Jul 2, 2021 at 5:51 AM Nikita Popov wrote: > As the partial function application RFC has not been accepted, I have > opened voting on https://wiki.php.net/rfc/first_class_callable_syntax. The > vote closes on 2021-07-16. > > This RFC uses a syntax that is forward-compatible with partial f

Re: [PHP-DEV] array_merge() inside looping optimization

On Sun, Jul 25, 2021 at 4:35 PM David Rodrigues wrote: > Anyway, I don't know if this is actually possible, or if the cost-benefit > would be better than what there is today. But I believe it is a path to be > thought of. > Sadly, no. The function doesn't know where the variable is going to be s

Re: [PHP-DEV] [RFC] Nullable intersection types

On Fri, Jul 23, 2021 at 4:58 AM Nicolas Grekas wrote: > https://wiki.php.net/rfc/nullable_intersection_types > > I've commented on the PR and in R11 a bit already, but I'd like to state my position here for the record. I do see the value in having nullability, but I can't disagree enough with th

Re: [PHP-DEV] [RFC] Under Discussion: Default User-Agent for cURL

On Tue, Aug 3, 2021 at 4:45 AM Hans Henrik Bergan wrote: > fwiw i think no self-respecting codebase is depending on an ini-setting > being correct for the ua in cases where the ua is actually important, so > the breakage should be minimal. > > In my mind, this is either an argument in favor of ei

Re: [PHP-DEV] Shut down gcov.php.net

On Wed, Aug 4, 2021 at 7:43 AM Nikita Popov wrote: > On Wed, Aug 4, 2021 at 2:25 PM Christoph M. Becker > wrote: > > > I suggest to shut down altogether. It is barely > > maintained for quite a while: PHP 7.4 builds are failing, and there are > > no PHP 8.0 builds at all.

Re: [PHP-DEV] Guidelines for RFC post feature-freeze

On Mon, Aug 23, 2021 at 5:57 PM Tobias Nyholm wrote: > > Situations like this often requires a judgement call rather than something > that could be defined as a policy. > I suggest the release managers always should be in agreement before a RFC > is created during a “feature freeze”. If the relea

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

On Wed, Aug 25, 2021 at 5:03 AM Nikita Popov wrote: > I'd like to propose the deprecation of "dynamic properties", that is > properties that have not been declared in the class (stdClass and > __get/__set excluded, of course): > > https://wiki.php.net/rfc/deprecate_dynamic_properties > > This RFC

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

On Thu, Aug 26, 2021 at 3:34 AM Nikita Popov wrote: > > The crux of the issue is what our end goal is: > > 1. Require users to explicitly annotate classes that use dynamic properties, > but otherwise keep dynamic properties as a fully supported part of the core language. > That's how I initially r

[PHP-DEV] PHP 8.0.11RC1 Available for testing

. Hash values and PGP signatures can be found below or at: https://gist.github.com/sgolemon/2fa8a0f29d635c3da844fbdaf0bc6609 8.0.11 should be expected in 2 weeks, i.e. on September 23rd 2021. Thank you, and happy testing! Regards, Gabriel Caruso & Sara Golemon php-8.0.11RC1.tar.gz SHA256

Re: [PHP-DEV] run-tests SKIPIF caching can be problematic for third-party extensions

On Wed, Sep 15, 2021 at 12:22 PM Jeremy Mikola wrote: > I just discovered that run-tests.php was changed to cache SKIPIF evaluation > since 8.1.0beta3[1]. I believe ext-mongodb ran into the same issue as > mysqli[2], as we use SKIPIF to check that database contents are clean going > into a test.

[PHP-DEV] PHP 8.0.11 Released

/download The list of changes is recorded in the ChangeLog: https://www.php.net/ChangeLog-8.php Many thanks to all the contributors and supporters! Sara Golemon and Gabriel Caruso Release Manifest here and below: https://gist.github.com/sgolemon/65bc563ad57d16069eaa7ab76b8f3046 php-8.0.11.tar.gz

Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?

On Sat, Sep 25, 2021 at 10:45 AM tyson andre wrote: > In PHP 8.1, it is possible to allow constructing any class name in an > initializer, after the approval of > https://wiki.php.net/rfc/new_in_initializers > > ``` > php > static $x1 = new ArrayObject(['key' => 'value']); > php > static $x2 = ne

Re: [PHP-DEV] Proposal: Shorthand initialization and destructuring of associative arrays

On Mon, Oct 4, 2021 at 2:15 PM Konrad Baumgart wrote: > > I have spare time this October, so I would happily get into php > interpreter by developing this. > Unfortunately my plans to have spare time FAILED and I'm not able to > contribute in the near future. > > I'm procrastinating writing slide

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

On Tue, Nov 2, 2021 at 9:19 AM Nikita Popov wrote: > The migration from bugs.php.net to GitHub issues has already been > discussed > in https://externals.io/message/114300 and has already happened for > documentation issues. > > I'd like to formally propose to use GitHub for PHP implementation is

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield wrote: > A possible idea to help make this transition (which I do support) more > gradual: > > Instead of an "allow" attribute, introduce a boolean flag attribute. > > #[DynamicProperties(true)] > class Beep {} > > The attribute marks whether dynami

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

Serious questions for all the folks worried that this is some kind of death nail for PHP. 1. Do you have code you're responsible for which uses dynamic properties so broadly that adding this attribute is a burden? 2. Do you know of real code in widespread use which uses dynamic properties so broad

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

On Tue, Nov 16, 2021 at 5:55 PM Larry Garfield wrote: > 1. If we adopt the RFC right now as-is, the market has ~12 months to add > the attribute. If we instead have a default-true flag that changes to > default false in the future, it means at minimum 24 months in which to add > the attribute to

[PHP-DEV] PHP 8 Release Announcement Page

In seven days, https://www.php.net/releases/8.0/en.php is going to be obsolete. Well, that's a harsh term, but it certainly won't reflect the current state on the ground, and we need to decide (should have decided, weeks ago) what we're going to do with it. 1/ Make a new announcement page for 8.1

[PHP-DEV] PHP 8.0.13 Released

/download The list of changes is recorded in the ChangeLog: https://www.php.net/ChangeLog-8.php Many thanks to all the contributors and supporters! Sara Golemon and Gabriel Caruso Release Manifest here and below: https://gist.github.com/sgolemon/3964ae5f68cc06798bc99497821540ef php-8.0.13.tar.gz

[PHP-DEV] Re: PHP 8.0.13 Released

On Thu, Nov 18, 2021 at 9:16 PM Sara Golemon wrote: > The PHP development team announces the immediate availability of PHP > 8.0.13. This is a security release fixing CVE-2021-21706. > > Whoops. Apologies for the copypasta error. That CVE number is a typo and should read CVE- 20

Re: [PHP-DEV] PHP 8 Release Announcement Page

On Fri, Nov 19, 2021 at 2:35 AM Nikita Popov wrote: > On Fri, Nov 19, 2021 at 4:16 AM Sara Golemon wrote: > >> In seven days, https://www.php.net/releases/8.0/en.php is going to be >> obsolete. >> >> Well, that's a harsh term, but it certainly won't refle

Re: [PHP-DEV] PHP 8 Release Announcement Page

On Fri, Nov 19, 2021 at 5:38 AM Rowan Tommins wrote: > Perhaps there should be a section at the end of the 8.1 page saying > something like "If you're still on PHP 7.x, upgrading gets you all this > as well!" with the headlines from the 8.0 page, and a link through. > > ^^ This. Maybe even a bre

[PHP-DEV] Sponsor link on github.com/php

Now that the new PHP Foundation has been announced, I've been asked if we'd mind configuring a Sponsor button on our github.com project profile. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-re

Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties

On Fri, Nov 26, 2021 at 12:16 AM Brady Wetherington via internals < internals@lists.php.net> wrote: > > > That's 1.5 million hours, which is 171 developer-years. > > > > If we're going to imagine numbers; there are 6 million PHP developers > > in the world*. If on average they each lose just 1 hou

Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties

On Tue, Nov 30, 2021 at 10:18 PM Brady Wetherington < bwethering...@grokability.com> wrote: > >>> …It's been merged to master, so you could stand up a build now and > point to the many deprecation warnings you're expecting. I'm not saying > send PRs to fix them all, just show real impact rather t

Re: [PHP-DEV] Allowing NULL for some internal functions

On Thu, Dec 2, 2021 at 8:48 AM Craig Francis wrote: > On Fri, 26 Nov 2021 at 16:47, Sara Golemon wrote: > > > I'm not saying send PRs to fix them all... Let's make PHP better, > > together. > > > > On a similar theme, trying to avoid too much work for

[PHP-DEV] PHP 8.0.14 RC1 Ready for testing

. Hash values and PGP signatures can be found below or at: https://gist.github.com/sgolemon/7e07a4a518e7714e95456823fe41e64c 8.0.14 should be expected in 2 weeks, i.e. on 16th December 2021. Thank you, and happy testing! Regards, Gabriel Caruso & Sara Golemon php-8.0.14RC1.tar.gz SHA256

[PHP-DEV] PHP 8.0.16RC1 Ready for testing

. Hash values and PGP signatures can be found below or at: https://gist.github.com/sgolemon/30338f5a826768c9ea39a4020ee2da8e 8.0.16 should be expected in 2 weeks, i.e. on 17th February 2022. Thank you, and happy testing! Regards, Gabriel Caruso & Sara Golemon php-8.0.16RC1.tar.gz SHA256

Re: [PHP-DEV] Multibyte strings

On Fri, Feb 11, 2022 at 12:26 AM Michał wrote: > It's a known fact that nowadays most websites use at least UTF-8 > encoding. Unfortunately PHP itself has stopped a bit in the previous > century. Is there any reason why the mbstring extension cannot be > introduced to core in the next major versi

Re: [PHP-DEV] Multibyte strings

On Fri, Feb 11, 2022 at 3:14 AM Rowan Tommins wrote: > There's also I think a myth in people's minds that something like > "string length" has a single meaning, and PHP gets it "wrong" for > multibyte strings; > This++. Unicode is not a static standard definition of all characters. New emoji

<    5   6   7   8   9   10   11   12   13   14   >