Re: [PHP-DEV] [VOTE] Support Closures in constant expressions

On 27-11-2024 22:58, Tim Düsterhus wrote: Hi On 11/27/24 22:50, Juliette Reinders Folmer wrote: One thing I'm wondering about - and of which I saw no mention in the RFC nor in the preceding discussion - knowing that function names are case-insensitive, how is ambiguity handled when _calli

Re: [PHP-DEV] [VOTE] Support Closures in constant expressions

On 27-11-2024 15:03, Tim Düsterhus wrote: Hi Am 2024-11-13 14:40, schrieb Tim Düsterhus: we just started the vote the the "Support Closures in constant expressions" RFC. Please find the following resources for your reference: RFC: https://wiki.php.net/rfc/closures_in_const_expr Implementatio

Re: [PHP-DEV] [RFC] [Discussion] Add get_declared_enums() function

On 4-10-2024 13:44, Nicolas Grekas wrote: Hi Nicolas, # Introduction of the new function: get_declared_enums() About this proposal, I shared a one-liner in the previous thread that shows listing only enums is trivial already. IMHO we don't need this function since the engine already provides

[PHP-DEV] [RFC] [Discussion] Add get_declared_enums() function

L.S., After the earlier discussion [1] regarding this topic in August, it is our pleasure to present the RFC to add a `get_declared_enums()` function to PHP for discussion. https://wiki.php.net/rfc/get_declared_enums We look forward to your feedback and hope for a constructive discussion. S

Re: [PHP-DEV] PHP 8.4 / Status of "Saner Increment/Decrement operator" part 2 ?

On 20-9-2024 13:59, Gina P. Banyard wrote: On Tuesday, 17 September 2024 at 19:04, Juliette Reinders Folmer wrote: L.s., I was just looking at the "Path to Saner Increment/Decrement operators" RFC [1] and as part of the proposal, step 2 "Deprecate using the increment op

[PHP-DEV] PHP 8.4 / Status of "Saner Increment/Decrement operator" part 2 ?

L.s., I was just looking at the "Path to Saner Increment/Decrement operators" RFC [1] and as part of the proposal, step 2 "Deprecate using the increment operator with non-numeric strings." should have gone into PHP 8.4, but I can't find anything about this deprecation having been added in PHP

Re: [PHP-DEV] bikeshed: Typed Aliases

On 6-9-2024 20:41, Rob Landers wrote: - This RFC expands the "use ... as ..." syntax to allow any type expression on the left side. These aliases are PER FILE and expire once the file is compiled. Explicitly without expressing any opinion about the RFC, I'd just like to remind you that `use

Re: [PHP-DEV] [RFC] Default expression

(resending as I accidentally originally send a private reply instead of sending the below to the list) On 24-8-2024 18:49, Bilge wrote: Hi gang, New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think some of you might enjoy this one. Hit me with any feedback. This one al

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

On 15-8-2024 3:51, Juliette Reinders Folmer wrote: L.S., I just noticed the following, which struck me as weird/inconsistent: There are four different OO structures in PHP: 1. Classes 2. Interfaces 3. Traits 4. Enums For all four, an `*_exists()` function is available, i.e. `class_exists

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

On 17-8-2024 6:26, Ayesh Karunaratne wrote: I think the `get_declared_enums` is small enough to be considered a minor change given we don't change any engine internals. Given the positive response on the mailing list, I think we can have this in PHP 8.4 as well, subject to RMs approval of cours

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

Hi Mike, There is one problem I can see with this approach though: since PHP 7.4, the return value of `get_declared_classes()` (and friends) does not guarantee any particular order anymore [2]. So, an `array_slice($symbols, $n)` may not get you the _latest_ classes loaded, so I think this w

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

On 17-8-2024 2:00, Mike Schinkel wrote: To everyone on this thread and thus nobody in specific (hence my top post): Given that get_declared_*() populates a new ZEND_HASH each time the function is called[1] — which for classes can easily be hundreds of strings — would there be any appetite to:

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

On 16-8-2024 17:01, Ayesh Karunaratne wrote: I went ahead and created PR https://github.com/php/php-src/pull/15443 along with tests, UPGRADE notice, etc. I think having a `get_declared_enums` function will be helpful. The implementation is simple and straightforward too. Thanks for creating

Re: [PHP-DEV] Time-out Posting to PHP Internals List

On 17-8-2024 0:50, Christoph M. Becker wrote: On 17.08.2024 at 00:36, Rob Landers wrote: But otherwise, I think it is healthy for it to be public. Voices silently silenced, even for a good reason, are never a good thing. Also, it gives people a chance to advocate for the banned or object to t

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

On 15-8-2024 15:09, Larry Garfield wrote: On Wed, Aug 14, 2024, at 8:51 PM, Juliette Reinders Folmer wrote: L.S., I just noticed the following, which struck me as weird/inconsistent: There are four different OO structures in PHP: 1. Classes 2. Interfaces 3. Traits 4. Enums For all four, an

[PHP-DEV] Should there be a `get_declared_enums()` function ?

L.S., I just noticed the following, which struck me as weird/inconsistent: There are four different OO structures in PHP: 1. Classes 2. Interfaces 3. Traits 4. Enums For all four, an `*_exists()` function is available, i.e. `class_exists()`, `interface_exists()`, `trait_exists()` and `enum_ex

Re: [PHP-DEV] Updates needed to various RFCs

Christoph, On 12-8-2024 0:18, Christoph M. Becker wrote: On 11.08.2024 at 22:21, Juliette Reinders Folmer wrote: Thanks Christoph! I was tempted to update the RFCs myself, but thought it was against protocol for anyone but the RFC owner to do so ? hence my email. Changing an open RFC without

Re: [PHP-DEV] Anyone willing to help out 3v4l ?

On 13-8-2024 5:12, Peter Kokot wrote: Should be fixed via https://github.com/php/php-src/pull/15373 All I can say: Thank you, gracious warrior and hero!

[PHP-DEV] Anyone willing to help out 3v4l ?

Hi all, I suppose everyone is aware of 3v4l.org and a lot of us use it on a regular basis. 3v4l also auto-builds the PHP "master" branch every night to allow for testing with the latest and greatest PHP version and comparing changes in behaviour against older PHP versions. Now, the auto-bu

Re: [PHP-DEV] Updates needed to various RFCs

On 11-8-2024 18:55, Christoph M. Becker wrote: On 11.08.2024 at 08:05, Juliette Reinders Folmer wrote: I'm currently going through the RFC wiki page and I'm seeing various (PHP 8.4) RFCs which haven't been properly updated after the vote. I've not gone through all of the

[PHP-DEV] Updates needed to various RFCs

L.S., I'm currently going through the RFC wiki page and I'm seeing various (PHP 8.4) RFCs which haven't been properly updated after the vote. I'm specifically referring to the updates which are expected to be made to an RFC as listed in point 7 and 8 in the "RFC How to" [1]. Typical example

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26-7-2024 16:20, Larry Garfield wrote: One thing to remind people about, the deprecations for md5(), sha1(), and uniqid() explicitly say they cannot be outright removed before PHP 10. That's at least 6 years away. That gives a loong time for documentation, tutorials, instructions, an

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26-7-2024 0:00, Nick Lockheart wrote: That's a good point. What if there were crypto functions that worked like password_hash() in that they had one generic function name, but magically used the new/better "best practice" algorithms as time went by without the need to update any calling code?

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

On 21-7-2024 17:11, Rowan Tommins [IMSoP] wrote: Oddly, the crux of this debate seems to be less that all options have major impact, and more that none of them do. If the implementation had caused a serious security or performance regression, I don't think we'd have any hesitation in backing it

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

On 21-7-2024 13:28, Ilija Tovilo wrote: Hi Ilja, I agree that it's not very likely that many people started placing comments between yield and from, but certainly not impossible. The main problem with reverting this change is that such code will completely stop working. Patch updates are routi

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

On 20-7-2024 18:04, Tim Düsterhus wrote: PHP users have no idea what a token is internally. I'm looking at this from a PHP user perspective. It looks like two keywords, it walks like two keywords and it quacks like two keywords. I find it reasonable for users to consider this as two keywords an

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

On 19-7-2024 1:09, Bob Weinand wrote: Hey Christoph, Am 19.07.2024 um 00:51 schrieb Christoph M. Becker : Hi Bob! On 18.07.2024 at 15:41, Bob Weinand wrote: Moreover, it can - at least - be worked around in tooling by special casing the T_YIELD_FROM token and extracting the comment from th

[PHP-DEV] Request for opinions: bug vs feature - change in tokenization of yield from

Hi all, I recently discovered a change was made to the Tokenizer in PHP 8.3.0 which now allows for a comment to exist between the `yield` and `from` keyword from the `yield from` keyword. Before PHP 8.3, this was a parse error. This change was not documented (anywhere) nor publicized, which i

Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers

On 10-7-2024 1:39, Gina P. Banyard wrote: On Thursday, 4 July 2024 at 14:52, Gina P. Banyard wrote: Moreover, I know the traffic on the list has been pretty high, but I do intend to have this RFC up for voting for inclusion in PHP 8.4, and I'm not exactly sure how I am meant to interpret the l

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 8-7-2024 6:57, Andreas Heigl wrote: Am 08.07.24 um 05:04 schrieb Juliette Reinders Folmer: [...] I also don't agree that there are "more appropriate replacements available". The suggested `hash()` replacements for the md5/sha1* functions have the exact same functionality

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

On 8-7-2024 5:18, Saki Takamachi wrote: Hi Juliette, Hi Saki, Just wondering: why `int|string` instead of `float|string` ? In my experience, floats are the more pertinent type for which to use the BCMath extension. Smile, Juliette Since floating point numbers always contain a certain amount

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 2-7-2024 20:05, Gina P. Banyard wrote: On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer wrote: On 25-6-2024 16:36, Gina P. Banyard wrote: Hello internals, It is this time of year again where we proposed a list of deprecations to add in PHP 8.4: https://wiki.php.net/rfc

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

On 8-7-2024 3:23, Saki Takamachi wrote: Hi all, I created an RFC and put it in discussion status. https://wiki.php.net/rfc/allow_int_args_to_bcmath_function It's a very simple RFC, so unless there's any major discussion, I plan to start voting on this on 7/23, after two weeks have passed. Reg

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On 25-6-2024 16:36, Gina P. Banyard wrote: Hello internals, It is this time of year again where we proposed a list of deprecations to add in PHP 8.4: https://wiki.php.net/rfc/deprecations_php_8_4 As a reminder, this list has been compiled over the course of the past year by various different

Re: [PHP-DEV] [RFC] [Discussion] Add bcdivmod to BCMath

On 30-6-2024 16:04, Saki Takamachi wrote: Hi internals, I created an RFC and put it in discussion status. https://wiki.php.net/rfc/add_bcdivmod_to_bcmath I expect return values ​​will probably be the main topic of discussion. Regards, Saki Just a suggestion: what about making the returned a

Re: [PHP-DEV] Add $this return type

On 25-6-2024 19:53, radar3301 wrote: Sebastian Bergmann said: [snip] please not "$this" as the name for a type. Off the top of my head, I think that "same" could make sense. My primary vote would still be for "$this" as explained above, but I could potentially be persuaded to switch to "this"

Re: [PHP-DEV] [DISCUSSION] Checking uninitialized class properties

On 20-5-2024 19:41, Erick de Azevedo Lima wrote: > All of which is to say that, yes, there are use cases for an "is this property initialized" check that is less fugly than the get_object_vars() hack I have to rely on now. I'd like to see this: if ($objectVar->property is uninitialized) { ...

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

On 11-5-2024 16:43, Gina P. Banyard wrote: On Thursday, 9 May 2024 at 15:17, Jorg Sowa wrote: > I don't think there are any other "functions" like this. What about list(), isset(), print(), echo(), require(), include(), unset(), empty()? We use them the same way as functions, but those are

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

On 8-5-2024 15:40, Gina P. Banyard wrote: I would like to formally propose my idea for exit() as a function brought up to the list on 2024-02-24 [1] with the following RFC: https://wiki.php.net/rfc/exit-as-function There have been some slight tweaks to the implementation, namely that the transf

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

Hi Ilija, On 12-4-2024 1:00, Ilija Tovilo wrote: On 9-4-2024 16:03, Juliette Reinders Folmer wrote: I realize it is late in the discussion period to speak up, but for months I've been trying to find the words to express my concerns in a polite and constructive way and have failed. Fir

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

On 9-4-2024 16:03, Juliette Reinders Folmer wrote: On 8-4-2024 23:39, Ilija Tovilo wrote: Hi everyone Heads-up: Larry and I would like to start the vote of the property hooks RFC tomorrow: https://wiki.php.net/rfc/property-hooks We have worked long and hard on this RFC, and hope that we have

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

On 8-4-2024 23:39, Ilija Tovilo wrote: Hi everyone Heads-up: Larry and I would like to start the vote of the property hooks RFC tomorrow: https://wiki.php.net/rfc/property-hooks We have worked long and hard on this RFC, and hope that we have found some middle-ground that works for the majority.

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

On 6-4-2024 14:55, Tim Düsterhus wrote: Hi On 4/5/24 23:32, Juliette Reinders Folmer wrote: I also took the liberty to ask accessibility expert Nicolas Steenhout [1] for his opinion on this topic and he has given me permission to quote his reply: > From a human readability and

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

On 5-4-2024 22:55, Larry Garfield wrote: On Fri, Apr 5, 2024, at 7:15 PM, Tim Düsterhus wrote: Hi On 4/5/24 20:01, Juliette Reinders Folmer wrote: In the "It decreases readability" section you make a sweeping statement about accessibility, but don't back that up with resear

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

On 5-4-2024 19:48, Niels Dossche wrote: On 05/04/2024 19:00, Tim Düsterhus wrote: I've just written up the follow-up RFC to my previous “Casing of acronyms in class and method names” thread and I'm officially opening up the discussion period for it. Please find the following links for your co

Re: [PHP-DEV] Re: [PHP-CVS] [php-src] master: Deprecate implicit nullable parameter types (#12959)

On 14-3-2024 15:55, Matteo Beccati wrote: Hi Sebastian, Il 14/03/2024 14:15, Sebastian Bergmann ha scritto: Am 14.03.2024 um 14:07 schrieb Matteo Beccati: In my daily CI I have several builds failing today, eg. * PHPUnit 9.6 See https://github.com/sebastianbergmann/phpunit/issues/5719. th

Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions

On 24-2-2024 3:47, Gina P. Banyard wrote: On Saturday, 24 February 2024 at 01:57, Juliette Reinders Folmer wrote: Hi Gina, I'm not sure a pet-peeve is a good motivation for creating an (I expect large) breaking change. The upgrade path, I suppose, would be updating calls to

Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions

On 24-2-2024 2:37, Gina P. Banyard wrote: Hello internals, I've been having this mild annoyance with exit()/die() since I wrote a CLI script using a boolean $hasErrors variable to know if the script failed or not and to indicate if the script failed via a non-zero status code by doing: exit($has

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

On 6-2-2024 3:40, youkidearitai wrote: 2024年2月6日(火) 8:33 Tim Starling : On 2/2/24 20:27, youkidearitai wrote: I see. I'll change mb_ucfirst using titlecase. Per my comments a month ago on the GitHub issue , I think it is much better to use title case for mb_ucfirst() than to use upper case, s

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

On 22-1-2024 10:50, Gina P. Banyard wrote: Hello internals, Máté Kocsis and myself would like to propose deprecating implicitly nullable parameter types. The RFC is available on the wiki at the following address: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types Best regards, Gin

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

On 23-1-2024 3:18, Gina P. Banyard wrote: The RFC notes that PHPStan and friends have an easy flag to make the change, which is great, but still that's a minority of PHP devs that even know to use static analysis. One does not need to use a static analyser to determine or fix this issue, inde

[PHP-DEV] What is the prevailing sentiment about extract() and compact() ?

L.S., What with all the drives towards cleaner code, how do people feel nowadays about `extract()` and `compact()` still being supported ? Both have alternatives. The alternatives may be a little more cumbersome to type, but also make the code more descriptive, lessens the risk of variable n

Re: [PHP-DEV] [RFC] [Discussion] Release cycle update

On 10-11-2023 17:51, Jakub Zelenka wrote: Hello, I would like to propose a new process RFC for updates to PHP release cycle: https://wiki.php.net/rfc/release_cycle_update This has been discussed between release managers to make sure that all are happy as some of the points impact release manag

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

On 15-9-2023 12:15, Dmitry Stogov wrote: Hi, After the code-review feedback, one of the most questionable decisions was changed. Instead of including IR Framework as a git submodule, now its part is embedded into php-src. This will complicate the IR/JIT development a bit, but will simplify thing

Re: [PHP-DEV] Casing of acronyms in class and method names

On 13-9-2023 17:48, Ben Ramsey wrote: On 9/10/23 20:59, Juliette Reinders Folmer wrote: With the above in mind, I wonder how much confusion/code churn renaming existing classes will cause and if that's worth it, especially as the suggested case for the PHP native class will likel

Re: [PHP-DEV] Casing of acronyms in class and method names

On 11-9-2023 1:57, Ben Ramsey wrote: I agree. Using uppercase for the first letter in an acronym and lowercase for subsequent letters appears to be prevalent in many userland libraries, so it seems to be what users expect. Since class names in PHP aren't case-sensitive, there should be no BC

Re: [PHP-DEV] Access property of object stored in a constant

On 18-8-2023 17:27, Ilija Tovilo wrote: Hi everyone Since https://wiki.php.net/rfc/new_in_initializers we can store objects in global constants. However, we may not actually read or write to the properties of those objects without first fetching the constant into a local variable. const a = new

Re: [PHP-DEV] Removing support for the disable_classes INI setting

On 14-8-2023 16:17, G. P. B. wrote: Hello internals, While working on some DNF type bugs, I discovered some major issues around the disable_classes INI setting implementation. Such as: - A double-free of the type of a typed property - A use after free (which segfaults) when trying to access a p

Re: [PHP-DEV] Updating the RFC list page

On 6-8-2023 13:13, Juliette Reinders Folmer wrote: RFC authors, I just noticed that the PHP 8.3 "PDO driver specific sub-classes" RFC is still listed as "in voting". The "Deprecate functions with overloaded signatures" RFC is still listed as "pending i

[PHP-DEV] Updating the RFC list page

RFC authors, I just noticed that the PHP 8.3 "PDO driver specific sub-classes" RFC is still listed as "in voting". The "Deprecate functions with overloaded signatures" RFC is still listed as "pending implementation". As far as I can see, both have been accepted/merged and can be moved to "Imp

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

On 19-6-2023 23:27, Máté Kocsis wrote: Hi Juliette, For the mb_strimwidth() proposal an impact analysis is provided at the end ("over 100 projects were reviewed"). For the other proposals there isn't and we do not believe this to be useful. We consider deprecations to be different from other RF

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On 19-6-2023 23:16, Máté Kocsis wrote: Hi, The impact analysis on userland code seems to be missing for some of the proposals, most notably for the proposals which I expect will have the highest impact. I'd like to ask for an impact analysis to be added to each of these: * array_keys() * Refl

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On 27-4-2023 23:28, Máté Kocsis wrote: Hi Internals, As you have possibly already experienced, overloaded signatures cause various smaller and bigger issues, while the concept is not natively supported by PHP. That's why I drafted an RFC which intends to phase out the majority of overloaded func

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

On 15-6-2023 9:18, Máté Kocsis wrote: Hi everyone, As there was no discussion and complaint for a long time, we would like to move forward with the RFC. We believe Go and Tim answered Nikita's doubts elaborately, so we should make the question decided during the vote. Therefore, we'll start the

Re: [PHP-DEV] [RFC] Interface Default Methods

On 15-6-2023 5:47, Levi Morrison via internals wrote: Hello, PHP Internals, I am moving my RFC for interface default methods to discussion: https://wiki.php.net/rfc/interface-default-methods. This can be a useful tool for a few reasons: 1. It can make implementing an interface easier when cer

[PHP-DEV] Unexpected behaviour when using Traits with final methods

Hi all, I'm running into something which peaked my curiousity due to its unexpected behaviour, so I'm writing to the list in the hopes of finding out whether this is by design, a bug or an oversight which should be fixed (via an RFC?). > The precedence order is that members from the current

Re: [PHP-DEV] RFC [Discussion]: Closure self-reference

On 3-6-2023 21:11, Dan Ackroyd wrote: Hi internals, I'm now opening the discussion for the Closure self-reference RFC: https://wiki.php.net/rfc/closure_self_reference This was previously discussed as a draft here: https://externals.io/message/112216#112216 Thank-you to KapitanOczywisty for the

Re: [PHP-DEV] Final anonymous classes

On 24-4-2023 12:28, Daniil Gentili wrote: Hi all, I've submitted https://github.com/php/php-src/pull/11126 to add support for final anonymous classes, though as noted by iluuu1994, it would probably make more sense to just make all anonymous classes final by default, what do you think? Dani

Re: [PHP-DEV] Array spread append

On 6-4-2023 0:12, Vorisek, Michael wrote: Hello, I would like to open a discussion for https://github.com/php/php-src/issues/10791 . [https://opengraph.githubassets.com/a23cb565cc8acac6a33ecab5d9ee68a46f046a1ffe215501673156e506695430/php/php-src/issues/10791]

Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2

On 2-11-2022 18:46, Benjamin Morel wrote: Hi internals, It just came to my attention that there is a change of behaviour between PHP 8.1 and 8.2 in the way iterable is decomposed, or not, into Traversable|array when reflected: ``` function foo(): iterable {} function bar(): stdClass|iterable {}

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Re: ***SPAM*** [PHP-DEV] Additional small features for 8.2

On 18-8-2022 19:12, Jakub Zelenka wrote: On Thu, Aug 18, 2022 at 5:11 PM Juliette Reinders Folmer < php-internals_nos...@adviesenzo.nl> wrote: On 18-8-2022 15:46, Jakub Zelenka wrote: Make libxml_set_external_entity_loader() return the previous loader https://github.com/php/php-src/pul

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] Additional small features for 8.2

On 18-8-2022 15:46, Jakub Zelenka wrote: Make libxml_set_external_entity_loader() return the previous loader https://github.com/php/php-src/pull/7977 Based on the PR, this introduces a new function to PHP/the `libxml` extension. Doesn't that need an RFC ? Note: I'm not opposed to the change

Re: [PHP-DEV] [RFC] Asymmetric visibility

On 5-8-2022 19:08, Larry Garfield wrote: Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: Asymmetric Visibility. https://wiki.php.net/rfc/asymmetric-visibility Details are in the RFC, but it's largely a copy of Swift's support for the same. For what it's worth, here's

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables

L.S., I have opened the vote on the "Expand deprecation notice scope for partially supported callables" RFC: https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices The vote will run for two weeks and will close on June 14, 10:30 UTC. The discussion threads about t

Re: [PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables

L.S., I have opened the vote on the "Expand deprecation notice scope for partially supported callables" RFC: https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices The vote will run for two weeks and will close on June 14, 10:30 UTC. The discussion threads about

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables

On 31-5-2022 12:38, Juliette Reinders Folmer wrote: L.S., I have opened the vote on the "Expand deprecation notice scope for partially supported callables" RFC: https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices The vote will run for two weeks and

[PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables

L.S., I have opened the vote on the "Expand deprecation notice scope for partially supported callables" RFC: https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices The vote will run for two weeks and will close on June 14, 10:30 UTC. The discussion threads about th

Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

Hi Dan, On 29-5-2022 17:34, Dan Ackroyd wrote: Actually, I've just realised there is an error in the code in the RFC, which might be based on a misconception caused by how terrible callables are. In the code: if (is_callable('static::methodName')) { // For valid callbacks, this call will b

Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

On 26-5-2022 20:23, Dan Ackroyd wrote: Hey Julie, On Thu, 26 May 2022 at 12:45, Juliette Reinders Folmer wrote: I propose to open the vote on this RFC tomorrow. Before you open the vote, please could you split the voting into two, one for the is_callable, and one for the callable type check

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

On 12-5-2022 18:54, Juliette Reinders Folmer wrote: After the prior discussion about the same topic: https://externals.io/message/117342, I have created an RFC to expand the scope of the deprecation notices being thrown for the deprecated partially supported callables to include is_callable

Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions

On 16-5-2022 17:06, Andreas Leathley wrote: Hello Internals, After the first discussion about this topic (https://externals.io/message/117608) I have created a preliminary implementation and an RFC for making implicit boolean type coercions more strict: https://wiki.php.net/rfc/stricter_implici

Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

On 12-5-2022 23:30, Claude Pache wrote: Le 12 mai 2022 à 23:11, Larry Garfield a écrit : For the `callable` type declaration, I'm not opposed but is it redundant with the existing deprecation? When would you pass a callable to something and not end up calling it anyway, which would trigge

[PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables

After the prior discussion about the same topic: https://externals.io/message/117342, I have created an RFC to expand the scope of the deprecation notices being thrown for the deprecated partially supported callables to include is_callable() and the callable type in PHP 8.2. With this email I

[PHP-DEV] Request for wiki karma

L.S., As per the progression of the discussion about the deprecated partially supported callable, a new RFC is needed to expand the scope of the deprecations. See: https://externals.io/message/117342 I'd like to request karma to create this RFC. Username: jrf Kind Regards, Juliette

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throw a deprecation notice ?

On 2-5-2022 14:43, Rowan Tommins wrote: On 02/05/2022 12:56, Alexandru Pătrănescu wrote: The point is that this is not an usual deprecation, something that will change to an error in the future. In the end, it's just a change in behavior with no error before or after. It does not fit the "depr

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

On 1-5-2022 9:54, Rowan Tommins wrote: On 1 May 2022 03:49:11 BST, Juliette Reinders Folmer wrote: As far as I understand it, if the deprecation notice is **only** thrown for the deprecated callables, the code can always be adjusted to use the recommended replacement code patterns as per

Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

On 29-4-2022 16:36, Rowan Tommins wrote: On 29/04/2022 03:04, Juliette Reinders Folmer wrote: And that's basically exactly what I already did which led me to discover the patterns I posted about as they looked concerning (though I didn't use Nikic's tool, but the WIP PHPCompa

Re: [PHP-DEV] Deprecated partially supportedcallables: should is_callable() throwa deprecation notice ?

On 28-4-2022 17:00, Christoph M. Becker wrote: On 28.04.2022 at 16:09, Juliette Reinders Folmer wrote: On 22-4-2022 8:47, Rowan Tommins wrote: On 22 April 2022 02:02:58 BST,php-internals_nos...@adviesenzo.nl wrote: I agree it would be a good idea to run a package analysis, but to be fair

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

On 28-4-2022 21:42, Rowan Tommins wrote: On 28/04/2022 15:09, Juliette Reinders Folmer wrote: Ah! So you're basically asking for the impossible. Search for a code pattern where a deprecation would not be useful, while noone has been able to come up with one. Not at all. I'm sayi

[PHP-DEV] Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

On 22-4-2022 8:47, Rowan Tommins wrote: On 22 April 2022 02:02:58 BST, php-internals_nos...@adviesenzo.nl wrote: I agree it would be a good idea to run a package analysis, but to be fair, in all honesty that should have been done for the original RFC, which was completely missing an impact a

Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throw a deprecation notice ?

On 22-4-2022 3:02, php-internals_nos...@adviesenzo.nl wrote: On 21-4-2022 21:56, Andreas Hennings wrote: On Thu, 21 Apr 2022 at 11:18, Rowan Tommins wrote: On Wed, 20 Apr 2022 at 19:16, Claude Pache wrote: You make a very important claim in your bug report: However, in real world, is_cal

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] Re: [RFC] Deprecate and Remove utf8_encode and utf8_decode

On 23-3-2022 14:46, Rowan Tommins wrote: On 20/02/2022 18:55, Rowan Tommins wrote: I would like to open discussion on an RFC to deprecate and later remove the functions utf8_encode() and utf8_decode() https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode Final chance for feedback on

[PHP-DEV] Re: Deprecated partially supported callables: should is_callable() throwa deprecation notice ?

On 18-3-2022 14:37, Christoph M. Becker wrote: On 16.03.2022 at 06:52, Juliette Reinders Folmer wrote: I've just been looking in detail at the Partially Supported Callables deprecation RFC: https://wiki.php.net/rfc/deprecate_partially_supported_callables The RFC explicitly exclude

[PHP-DEV] Deprecated partially supported callables: should is_callable() throw a deprecation notice ?

L.s., I've just been looking in detail at the Partially Supported Callables deprecation RFC: https://wiki.php.net/rfc/deprecate_partially_supported_callables The RFC explicitly excludes the `is_callable()` function and the `callable` type from throwing deprecation notices. The |is_callable